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From  the  Sponsor 

Planning  for  Software  Acquisition,  Development,  and 
Sustainment  in  a  Complex  Systems  Environment 

As  the  demand  for  software  acquisition  and  development  expertise  continues  to  rise 
in  an  environment  of  limited  resources,  we  must  ensure  that  programs  engage 
software  expertise  early  in  the  system  life  cycle  and  that  the  program  has  tools  and 
processes  in  place  that  enable  distributed  teams  to  work  effectively  across  geographic 
boundaries.  Best  practices  highlight  the  importance  of  taking  the  necessary  planning  in 
The  Beginning  of  a  project  to  properly  design  a  way  to  reach  the  desired  outcome. 

Acquisition  of  software -intensive  systems  in  today’s  rapidly  evolving  technological 
environment  is  a  challenging  task.  Consistency  of  processes  for  estimating  scope,  size,  and  com¬ 
plexity  of  software  is  often  lacking.  Requirements  are  often  unstable  or  incomplete  and  are  not 
adequately  allocated  down  to  the  software  domain,  the  results  of  which  may  include  excessive 
rework,  cost,  and  schedule  overruns,  as  well  as  poor  quality  products. 

We  know  that  up-front  planning  helps  teams  save  money  and  deliver  a  better  product  to  the 
customer.  Through  various  methods  teams  consistently  use  requirements  to  generate  the  tasks 
necessary  to  create  the  product.  This  issue  of  CROSSTALK  focuses  on  ways  to  maximize  the 
conversion  of  project  requirements  to  an  effective  task  plan. 

When  you  read  Ellen  Gottesdiener’s  article  Good  Practices  for  Developing  User  Requirements^  take 
note  of  how  she  dissects  an  effective  approach  for  defining  user  requirements.  For  a  deeper 
understanding  of  various  methods  of  state  machine-based  design  to  perform  software  devel¬ 
opment  read  Markus  Herrmannsdorfer,  Dr.  Sascha  Konrad,  and  Brian  Berenbach’s  Tabular 
Notations  for  State  Machine-based  Specifications.  Interoperability  and  secure  data  sharing  in  a  real-time 
operational  environment  are  discussed  in  Dr.  Douglas  C.  Schmidt,  Dr.  Angelo  Corsaro  and 
Hans  Van’t  Hag’s  article  Addressing  the  Challenges  of  Tactical  Information  Management  in  Net-Centric 
Systems  With  DDS.  Learn  how  the  technical  process  and  people  came  together  successfully  on  a 
geographically  distributed  project  in  NAVAIR’s  Coast  to  Coast  Support  of  the  E-2C  Hawkey e  Using 
Distributed  TSP  by  Linda  Lou  Crosby  and  Jeff  Schwalb.  Also  included  in  this  issue  of 
CROSSTALK  is  experimental  data  gathered  by  Dr.  David  J.  Coe  and  his  University  of  Alabama 
students  leading  to  recommendations  for  improving  the  consistency  of  the  estimation  process 
in  Improving  Consistency  of  Use  Case  Points  Estimates. 

As  software  assumes  an  ever-increasing  role  in  the  acquisition,  development,  and  sustain¬ 
ment  of  evolving  capabilities  within  Department  of  Defense-fielded  systems,  the  need  for 
robust  up-front  planning  of  software  related  activities,  processes,  best  practices  and  events  as  an 
integrated  component  of  the  overall  system  throughout  the  entire  systems  engineering  life  cycle 
is  vital  to  program  success.  The  future  holds  great  promise.  With  accelerating  technology  and 
great  planning  we  will  have  a  skilled,  trained,  workforce  that  shares  a  common  vision  and  oper¬ 
ates  in  an  integrated  fashion  to  achieve  a  clear  set  of  goals.  Effective  planning  at  the  outset  of 
every  project  is  crucial  to  meet  the  challenges  of  the  future. 


Joan  Johnson 

Naval  Air  Systems  Command 


March  2008 


www.stsc.hill.af.mil  3 


The  Beginning 


NAVAIR’s  Coast-to-Coast  Support  of  the 
E-2C  Hawkeye  Using  Distributed  TSP 


Linda  Lou  Crosby  Jeff  Schwalb 

NAVAIR  People,  Process,  Products,  and  Resources  Team  NAVAIR  Systems / Software  Support  Center  Team 


This  article  discusses  the  Pd  aval  Air  Systems  Command  ( NATAIRJ  distributed  team  that  became  an  example  of  how  pro¬ 
jects  can  work  together  remotely  and  be  successful.  This  was  accomplished  through  the  use  of  common  processes  extended  to 
multiple,  distributed  teams,  their  coaches,  and  the  tools  used  to  automate  those  processes.  The  other  vital  area  addressed  was 
the  organisational  cultures  to  be  connected.  This  meant  an  important  understanding  of  each  other's  assumptions,  values,  and 
styles  needed  to  happen.  This  article  is  filled  with  observations  and  lessons  learned  from  team  members,  team  coaches,  and 
organisational facilitators  on  the  multi-site  virtual  merging  of  NAVAIR  E-2C  Hawkeye  software  developers  at  Patuxent 
River,  MD  with  F-14D  software  developers  at  Point  Mugu,  CA. 


The  challenge  facing  the  E-2C  program 
at  Patuxent  River  in  Maryland  in  2003 
was  one  of  simply  having  more  work  than 
the  engineers  could  perform  in  the  time 
allotted.  At  the  same  time,  engineers  at 
Point  Mugu  in  California  were  working  on 
the  F-14D  delivering  its  final  block  release 
to  the  fleet.  When  E-2C  leadership  discov¬ 
ered  the  available  pool  of  engineers  at  Point 
Mugu,  the  question  became  one  of  how  to 
successfully  combine  these  two  groups  of 
engineers  into  one  distributed  team. 

E-2C  leadership  at  the  time  was  aware 
of  the  F-14A/B/D  model  aircraft  sun  set¬ 
ting  and  the  fact  that  many  talented  soft¬ 
ware  engineers  were  becoming  available  for 
other  work.  The  F-14  Integrated  Product 
Team  at  Point  Mugu  saw  working  with  E- 
2C  as  an  opportunity  to  place  their  software 
engineers  into  a  team  with  a  bright  future. 
F-14  leadership  briefed  the  E-2C  leadership 
on  the  capabilities  of  these  software  engi¬ 
neers  as  part  of  their  effort  to  find  a  future 
home  for  them.  Their  Team  Software 

SM  Team  Software  Process,  Personal  Software  Process,  TSP, 
and  PSP  are  service  marks  of  Carnegie  Mellon  University. 


ProcessSM  (TSPSM)  credentials  were  so 
impressive  that  the  E-2C  program  decided 
it  was  worth  the  extra  effort  involved  in 
having  virtual  teams  employed  on  their 
upcoming  software  development  projects. 

Members  from  the  two  sites  became 
two  integrated  teams,  one  for  the  E-2C 
Mission  Computer  (MC)  and  one  for  the 
displays  on  board.  The  E-2C  Leadership 
asked  the  NAVAIR  Process  Improvement 
(PI)  enterprise  team  for  an  approach  to 
establish  this  virtual  software  engineering 
team.  They  would  start  with  TSP  to  estab¬ 
lish  a  process  engineering  framework  due 
to  its  success  with  other  NAVAIR  projects 
[1].  You  will  hear  about  three  things  in  this 
article:  TSP  and  its  ability  to  support  multi¬ 
ple,  distributed  teams,  cultural  change  and 
how  people  were  supported  as  the  distrib¬ 
uted  team  started,  as  well  as  responses 
about  how  this  effort  evolved  and  what 
they  think  of  it  now  as  they  still  continue  to 
work  together  five  years  later. 

TSP 

To  start,  we  will  provide  a  quick  review  of 


basic  TSP  followed  by  the  extensions  of  the 
multiple,  distributed  team  version  applied  to 
E-2C.  The  basic  TSP  is  a  software  engineer¬ 
ing  process  framework  created  by  the 
Software  Engineering  Institute  (SEI)  to  help 
a  team  plan  its  work  and  then  work  that  plan 
through  collection  of  measures,  regular  com¬ 
munications,  and  replanning  at  milestones 
along  the  way  to  delivery  of  products  [2]. 
The  fundamentals  are  displayed  in  Figure  1 . 

The  TSP  starts  by  building  a  common 
language  between  software  engineers  on  a 
team  by  training  them  in  the  Personal 
Software  ProcessSM  (PSPSM)  that  they  will  each 
use  [3].  This  training  uses  both  lectures  and 
exercises  so  that  engineers  gain  knowledge 
and  experience  in  the  use  of  the  process 
scripts  they  will  use,  collection  of  basic  mea¬ 
sures  used,  and  derivation  of  metrics  from 
those  measures  so  that  project  plans  and 
actuals  can  be  brought  together  to  have 
quantitative  project  status  on  a  weekly  basis. 

The  beginning  of  the  real  project  work  is 
the  launch  [4].  It  is  a  set  of  nine  very  struc¬ 
tured  and  detailed  planning  meetings  that 
start  by  communicating  with  project  stake- 


F-14D  Tomcat  -  United  States  Navy’s  primary  maritime  air  superiority  E-2C  Hawkeye  -  Nay’s  all-weather,  carrier-based  tactical  battle  manage- 
fighter,  fleet  defense  interceptor  and  tactical  reconnaissance  plaform  from  ment  airborne  early  warning,  command  and  control  aircraft  for  the  Carrier 

1974  to  2006.  Strike  Group  and  Joint  Force  Commander. 
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Figure  1 :  TSP  Approach  of  Training,  Planning,  and  Operations 


holders  to  obtain  needs,  wants,  and  desires. 
From  this  the  team  will  proceed  with  identi¬ 
fication  of  roles,  goals,  products,  and  ser¬ 
vices.  Then  they  proceed  with  the  top-down 
and  bottom-up  plans  necessary  to  have  each 
member  of  the  team  own  a  balanced  work¬ 
load  of  tasks  that  allow  two  to  four  tasks  to 
be  accomplished  each  week.  This  way,  when 
the  team  becomes  operational  after  launch 
each  person  is  able  to  know  if  they  are  mak¬ 
ing  progress  or  if  they  need  to  shift  tasks 
with  their  teammates. 

While  Figure  1  shows  a  launch  happen¬ 
ing  at  requirements  time,  a  project  may  actu¬ 
ally  start  TSP  anywhere  in  its  life  cycle  based 
upon  the  next  opportune  time  to  do  so.  For 
example,  if  a  project  wishes  to  apply  TSP  for 
the  first  time  and  is  currently  developing 
requirements,  then  it  will  obtain  the  TSP 
training  sometime  shortly  before  the  high- 
level  design  phase  and  then  launch  after 
requirements  are  complete. 

Another  feature  of  TSP  is  planning  an 
entire  project  from  top-down  at  the  begin¬ 
ning  and  then  re-planning  as  milestones 
along  the  way  are  reached.  This  is  because 
the  level  of  detailed  planning  done  in  TSP 
should  not  exceed  three  to  six  months  due 
to  reasonable  horizons  of  work  being 
done  and  the  idea  of  working  from  mile¬ 
stone  to  milestone.  While  Figure  1  shows  a 
simple  waterflow  model,  a  team  may 
instead  choose  other  strategies  where 
example  project  cycles  develop  iteratively 
functional  versions  of  a  project.  A  typical 
multi-year  project  will  go  through  several 
cycles  of  bottom-up  planning  as  it  moves 
from  one  milestone  to  the  next. 

Distributed  Team 

To  recap,  the  E-2C  program  was  doing  two 
things  with  TSP.  It  was  using  multiple  project 
teams  to  deliver  its  product  and  in  virtual 
teams  that  were  distributed  between  Maryland 
and  California.  Each  project  team  is  self- 
coordinated,  with  each  member  acting  in 
one  of  several  technical,  support,  or  lead 
roles  that  coordinates  all  these  efforts.  Each 
of  the  E-2C  project’s  leads,  planning  coordi¬ 
nators,  and  quality  coordinators  would  come 
together  in  key  parts  of  a  multi-team  launch. 
Planning  coordinators  came  together  before 
and  after  top-down  and  bottom-up  plan 
meetings  to  check  status  and  test  any 
assumptions.  Quality  managers  meet  after 
the  quality  plans  have  been  generated  to  do 
the  same.  Also,  at  the  end  of  each  day  of 
launch  the  leadership  team,  consisting  of 
each  project  lead  and  the  coaches,  convene 
to  check  status  and  discover  any  horizontal 
issues  that  may  affect  each  other. 

Shown  in  Table  1  is  recent  data  from  the 
E-2C  distributed  team  plans.  Teams  were 
constructed  based  upon  expertise  and  inter¬ 


est  of  engineers.  The  E-2C  teams  as  shown 
have  a  good  handle  on  their  plans  and  prod¬ 
ucts.  These  teams  effectively  planned  their 
work  every  four  to  six  months  to  the  level  of 
granularity  as  described  previously.  These 
launches  were  conducted  with  the  smaller 
portion  of  the  team  typically  traveling  to 
allow  the  entire  team  to  get  together.  This 
face-to-face  planning  style  was  vital  to  main¬ 
taining  trust  in  the  virtual  team. 

Operationally  these  teams  know  where 
they  are  with  ongoing  weekly  communica¬ 
tions  via  teleconference.  These  teams  chose 
to  break  up  their  weekly  communications. 
The  first  is  a  TSP  data-driven  meeting  to 
track  progress,  as  shown  in  Table  2  (see  page 
6).  The  other  weekly  teleconference  meeting 
is  used  to  discuss  technical  issues.  The  key  is 
that  these  teams  are  planning  their  work  and 
then  working  those  plans  for  constant 
improvement. 


Cultural  Change 

To  address  the  culture  change  needed  to  join 
the  two  teams,  the  NAVAIR  Organizational 
Development  (OD)  team  would  work  the 
people  issues  as  the  PI  team  focused  on 
processes.  NAVAIR  sites  had  traditionally 
been  perceived  as  competitors  to  each  other; 
this  is  a  difficult  barrier  to  break  down  as 
many  of  our  working  systems  still  support 
this  perception.  Also,  the  folklore  within 
each  site  includes  stories  of  past  competi¬ 
tion.  We  needed  new  stories  of  successful 
collaboration  to  replace  the  competition  sto¬ 
ries.  This  team  saw  the  possibilities  and  we 
built  on  that. 

Part  of  the  challenge  in  this  effort  was 
the  culture  ingrained  at  each  NAVAIR  site.  A 
Software  Support  Activity  (SSA)  maintains 
and  delivers  the  software  needed  to  bring 
high  tech  capabilities  to  today’s  advanced  air¬ 
craft.  Without  software,  the  aircraft  would  be 


Table  1 :  E-2C  Distributed  Project  Teams 


Team 

Members 

Project 

Project 

Type 

Pax 

Point 

Mugu 

Tasks 

Weeks 

Tasks/ 
Eng  / 
Week 

Cycle 

Complete 

Date 

Hours 

(planned/ 

actual) 

Earned 

Value 

(planned/ 

actual) 

A 

8 

4 

780 

16 

4.06 

12/2006 

1.97 

1.37 

A 

8 

4 

800 

24 

2.78 

7/2007 

0.95 

1.22 

B 

4 

12 

1788 

24 

4.66 

12/2006 

1.13 

1.18 

B 

4 

12 

1713 

24 

4.46 

5/2007 

1.12 

1.06 

A=Advanced  Control  Indicator  Set  B=MC 
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The  Beginning 


□  What’s  happening  outside  the 
project? 

□  Each  role  coordinator  reports 

□  Goals 

□  Risks 

□  Project  status  (plans  vs.  actuals) 

□  Upcoming  tasks  and  special  events 


Table  2:  Weekly  TSP  Team  Meeting  Typical 
Agenda 


unable  to  deliver  today’s  precision  weapons. 
Traditionally,  members  of  an  SSA  were  co¬ 
located  because  all  had  to  be  close  to  the  sim¬ 
ulation/test  lab  where  they  produced/modi¬ 
fied  the  software  and  tested  it.  For  example, 
F/A-18  and  AV-8B  at  China  Lake,  F-14D  at 
Point  Mugu,  E-2C  at  Patuxent  River,  MD, 
and  so  forth.  With  the  advances  in  technolo¬ 
gy,  the  availability  of  high-speed  communica¬ 
tions  lines  has  gone  up  and  costs  have  low¬ 
ered,  allowing  virtual  teaming  to  become 
much  more  common.  If  anything,  it  is  now 
the  culture  -  norms,  customs,  traditions  — 
that  seem  to  stand  in  the  way  of  increasing 
the  use  of  virtual  teams. 

E-2C  leadership  announced  from  the 
start  that  the  teaming  arrangement  would  not 
be  one  of  developer  and  subcontractor,  but 
rather  a  single  integrated  team  —  a  true  part¬ 
nership.  One  benefit  from  this  partnership  is 


increased  resources.  Pax  needed  more  engi¬ 
neers  and  Point  Mugu  needed  more  work. 
Without  that  relationship,  they  would  not 
have  been  able  to  give  the  fleet  all  the  want¬ 
ed  and  needed  functionality  -  the  benefit 
being  that  E-2C  would  generate  more  work 
for  itself  and  help  the  program  grow.  In  the 
end,  the  program  thought  it  could  be  used  as 
an  example  to  follow  when  considering  a 
successful  multi-site  team. 

According  to  the  OD  team,  the  challenge 
was  pretty  clear:  NAVAIR  has  been  produc¬ 
ing  software-intensive  products  for  decades 
so  the  knowledge  for  software  exists  with  the 
people  all  across  the  NAVAIR  sites.  Bringing 
teams  together,  rather  than  hiring  new  people 
into  a  site,  is  more  efficient  because  the  cost 
of  recruitment  and  training  is  not  needed. 
Instead,  the  investment  is  made  in  building  a 
team  rather  than  in  training  in  the  software 
domain.  The  people  who  came  together  on 
this  team  already  had  the  NAVAIR  knowl¬ 
edge  and  knew  how  to  develop  good  quality 
software.  They  just  needed  to  learn  how  to 
work  together  from  across  the  country 

Team  Building 

Building  the  virtual  teams  was  accomplished 
with  two  initial  events.  The  first  was  a  three 


day  initial  gathering  in  June  2003  designed  to 
start  the  building  of  a  new  common  culture. 
Its  objectives  were  the  following: 

1.  Get  every  team  member  to  meet  and 
greet,  get  to  know  each  other,  and  have 
some  fun. 

2.  Share  history  of  each  subgroup  and 
establish  a  vision  of  the  future  for  this 
newly  formed  team. 

3.  Establish  team  operating  principles 
and  obtain  team  agreement  on  basic 
operations. 

4.  Identify  communications  methods  and 
processes  for  initial  team  operations. 
To  meet  these  objectives,  the  first  day 

was  conducted  as  a  set  of  outdoor  activi¬ 
ties  to  get  everyone  to  know  each  other 
and  have  fun.  Activities  were  conducted  in 
a  park  on  base  at  Pax  and  included  various 
games  such  as  the  following: 

•  Celebration  of  success  —  developing 
ways  to  do  so. 

•  Reflection  —  what  in  your  past  will 
contribute  to  success. 

•  Picture  cards. 

•  Ah-So-Koh  circle. 

•  Newspaper  talk  —  sharing  information. 

•  Climbing  wall. 

•  Hula  hoop  lift. 

•  Reflection  —  personal  plan,  etc. 


Table  3:  Individual  Feedback 


Project 

Location 

Comments 

Mission 

Computer 

Point  Mugu 

Team  building  was  valuable:  “Although  some  distrust  levels  were  still  around  after  the  team  building 
event,  the  event  lay  the  foundation  for  the  groups  to  build  a  functional  team  to  achieve  the  common 
goals.” 

Foreign 

Military 

Sales 

Point  Mugu 

Had  his  doubts  initially  but  realized  E-2C  was  serious:  “...when  1  saw  the  effort  going  in  at  PAX  to 
provide  the  training,  tools,  and  resources  necessary  to  get  the  job  done  here  at  Point  Mugu,  1  knew 
management  was  really  supporting  this.” 

Mission 

Computer 

Point  Mugu 

Results  were  the  key:  “After  successfully  delivering  many  projects  within  schedule  for  the  Version-5  fleet 
release,  1  realized  that  the  distributed  approach  was  going  to  work.  If  people  did  not  work  together  as  a 
team  to  solve  problems,  they  simply  could  not  achieve  such  results.  Since  it  was  the  first  project,  working 
together  to  deliver  Version-5  was  the  most  difficult.  Several  projects  after  that  were  flying  smoothly.” 

Display 

Pax 

Attributes  team  success  to  TSP.  Has  been  a  team  member  since  March  2004,  develops  requirements 
and  detailed  design  documentation:  “TSP  provides  organization  and  communications;  as  a  developer, 
you  know  exactly  what  is  expected  from  you  from  the  start  of  the  project.  Both  managerial  and  team 
expectation.  In  order  to  accomplish  those  objectives,  you  need  to  have  strong  communication  within  the 
teams.” 

Mission 

Computer 

Point  Mugu 

Technology  was  an  issue:  “1  think  the  biggest  challenge  was  and  is  operating  a  classified  network  across 
the  country.  Not  so  much  because  the  technology  is  not  there,  but  because  of  all  the  security  hoops  that 
we  have  to  go  through  to  get  our  network  approved.” 

Leadership 

Pax 

Technology  also  helped:  “Technology  aided  in  allowing  this  team  to  work  together.  We  were  able  to 
establish  a  network  across  country,  which  allowed  the  use  of  a  common  data  repository  and  common 
processes  to  be  used.  For  example,  everyone  at  both  sites  used  the  same  configuration  management 
system.” 

Display 

Pax 

Had  previous  experience  on  a  distributed  team,  and  did  not  like  it:  “It  was  not  well  coordinated  and  1 
always  felt  like  we  were  the  poor-stepchildren  in  the  process.”  This  time  the  approach  was  completely 
different:  “There  is  high  coordination  and  management  attention  to  the  issues  involved  technically  in 
making  it  work  smoothly.  1  know  that  this  time  1  am  on  the  big  side  (East  Coast)  and  so  that  may  make 
things  different,  but  1  think  that  there  is  much  more  sense  that  the  West  Coast  folks  are  real  team 
members,  not  just  hired  help.” 

Mission 

Computer 

Point  Mugu 

Importance  of  communicating  across  the  sites:  “The  biggest  challenge  was  communication.  Several 
conference  calls  and  meetings  between  the  two  sites  took  place.  Several  visits  were  made  by  team 
management  so  they  could  know  every  team  member  and  build  the  bridge  between  them.  These  efforts 
definitely  helped.” 
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1.  Have  a  project  plan.  Everyone  should  know  the  mission  and  goals.  Each 
member  should  know  who  is  responsible  for  what  and  when. 

2.  Learn  about  available  resources  from  each  other.  How  many  developers  are 
available  and  what  skills  or  talents  does  each  individual  have?  What  equipment 
and  tools  are  there  for  development  and  testing? 

3.  Communicate  with  each  other  and  communicate  often.  Plan  weekly 
meetings,  plan  face-to-face  meetings,  e-mail,  and  call  often. 

4.  Trust  each  other.  Team  members  should  respect  and  understand  each  other. 

5.  Share  information.  Team  members  should  share  what  they  know  and  what 
they  learn  with  everyone  else. 

6.  Work  to  your  plan  and  goals. 


Table  4:  Six  Factors  That  Produce  Success  for  a  Multi-Site  Team 


The  second  and  third  day  events  were 
conducted  indoors  with  the  goal  of 
increased  understanding  through  historical 
and  present-day  perspectives.  Many  of  the 
outcomes  of  the  games  and  adventures  of 
the  first  day  would  be  available  for  use  in 
this  second  and  third  day  of  team  building. 
Activities  included  the  following: 

•  Team  introductions. 

•  Team  history. 

•  E2C  lab  tour. 

•  Myers-Briggs  Type  Indicator  workshop. 

•  Strengths  /  weaknesses  /  opportunities  / 
constraints  chart  developed  by  the 
team. 

•  Gap  analysis  determined,  solutions  pro¬ 
posed,  and  actions  assigned  to  team 
members. 

•  Team  members  built  joint  vision  for  the 
future. 

•  Team  members  drafted  team  agree¬ 
ment,  mission,  and  vision. 

The  second  event  was  performed  about 
eight  months  into  the  projects  in  February 
2004.  A  follow-up  with  E2-C  project  teams 
was  performed  by  conducting  confidential 
interviews  at  both  sites.  From  topics  that 
emerged,  a  set  of  team-building  topics 
were  presented  to  team  leaders  for  possible 
follow  up.  One  of  the  most  impressive  dis¬ 
coveries  from  the  confidential  interviews 
was  that  communication  between  the  two 
sites  and  team  members  was  going  well  -  a 
big  plus! 

Observations 

While  engineering  process  and  cultural 
change  were  important  in  making  this  E-2C 
multi-distributed  team  get  started,  we  were 
most  interested  in  the  people  themselves  and 
what  they  thought.  With  evolving  require¬ 
ments  and  launches  accordingly,  these  pro¬ 
jects  still  exist  and  operate  in  very  much  the 
same  distributed  way  as  they  started  nearly 
five  years  ago.  While  that  says  a  lot,  we  want¬ 
ed  to  know  what  real  participants  said  (see 
Table  3). 

A  member  of  one  E-2C  team  did  a  good 
job  showing  some  of  the  fundamental  places 
where  PI  and  cultural  change  (see  Table  4) 
took  place.  Individuals  of  a  team  located  in 
different  places  must  know  and  trust  each 
other  to  plan  their  work  and  then  track  it.  To 
do  so,  historical  data  must  be  collected  and 
used  for  tracking  and  improved  planning. 

Conclusions 

It  is  important  to  understand  that  real  people 
are  the  key  to  any  technology  improvement 
being  successful,  especially  when  it  is  a  dis¬ 
tributed  team.  The  important  thing  for  read¬ 
ers  to  realize  is  that  their  situation  could 
accomplish  the  same  great  success  with  the 
buy-in  of  people  from  their  organization. 


The  immediate  result  was  the  F-14D 
engineers  were  given  a  new  lease  on  life, 
while  E-2C  welcomed  some  incredibly  well- 
versed  and  knowledgeable  people  into  their 
program.  Long-term  results  (continued 
excellence  in  delivering  software  products  to 
the  Fleet)  show  that  people  with  similar  train¬ 
ing  and  skills  can  move  laterally  in  an  organi¬ 
zation  and  continue  to  make  a  solid  contri¬ 
bution.  Finally,  the  overall  experience  shows 
that  two  separate  organizations  must  remem¬ 
ber  the  importance  of  considering  cultural 
factors  when  bringing  teams  together. 

As  for  the  future,  it  is  full  speed  ahead, 
and  more  of  the  same  for  the  E-2C  multi- site 
team.  With  initial  concerns  a  thing  of  the 
past,  the  E-2C  team  can  fully  focus  on  the 
Hawkeye  mission.  E-2C  is  right  on  target  and 
they  set  a  great  example  for  others  to  follow 


in  proving  that  miles  don’t  matter  when  it 

comes  to  having  a  successful  Integrated 

Product  Team.^ 
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Improving  Consistency  of  Use  Case  Points  Estimates 

Dr.  David  J.  Coe 

University  of  Alabama,  Huntsville 

Use  cases  document  key  product  functionality  and  have  been  used  as  the  basis  for  estimating  software  product  development 
efforts.  Presented  here  is  experimental  data  on  the  use  of  the  Use  Case  Points  (UCP)  method  to  estimate  development  effort 
for  a  semester-scale  software  product.  From  a  common  set  of  initial  requirements,  six  student  teams  refined  these  requirements 
and  produced  independent  effort  estimates  from  their  own  use  case  models.  The  sources  of  estimation  inconsistency  are  exam¬ 
ined  and  recommendations  for  improving  the  consistency  of  the  estimation  process  are  presented. 


Use  cases  are  a  common  technique  for 
documenting  software  requirements. 
A  use  case  is  often  defined  as  a  step-by-step 
description  of  the  interaction  between  the 
software  and  one  or  more  actors  (the  peo¬ 
ple  or  other  systems  that  utilize  the  soft¬ 
ware  product  to  complete  a  given  task).  A 
use  case  model  of  a  software  product  is 
thus  the  set  of  all  use  cases  that  describe 
the  product’s  desired  functionality.  Well- 
written  use  cases  concisely  summarize 
product  functionality  in  a  way  that  is  easy 
for  customers  to  understand.  They  may 
also  provide  early  insight  on  project  com¬ 
plexities  and  give  software  developers  a 
starting  point  from  which  to  estimate  total 
development  effort.  The  UCP  estimation 
method  was  proposed  by  Gustav  Karner 
as  a  way  of  estimating  resources  for  pro¬ 
jects  developed  using  the  Objectory 
methodology  (which  later  evolved  into  the 
Unified  Process)  [1-2]. 

The  UCP  method  takes  into  account 
the  complexities  of  the  use  cases  them¬ 
selves  and  the  complexities  of  the  users 
(or  actors)  that  will  interact  with  the  soft¬ 
ware  product.  A  weighted  equation  based 
upon  the  number  of  steps  in  each  use  case 
and  the  complexities  of  the  actors  deter¬ 
mines  an  initial  UCP  estimate.  This  initial 
estimate  is  then  scaled  by  a  technical  fac¬ 
tor,  to  adjust  the  estimate  by  the  product’s 
perceived  technical  challenges,  and  by  an 
environmental  factor,  to  adjust  the  esti¬ 
mate  for  people-related  factors  such  as 
skill  levels,  experience,  motivation,  etc. 
The  scaled  UCP  estimate  may  then  be 
used  to  estimate  development  effort  by 
multiplying  it  by  an  experimentally  derived 
Productivity  Factor  (PF).  The  mechanics 
of  the  UCP  calculation  resemble  that  of 
Albrecht’s  Function  Point  method  from 
which  this  method  was  derived  [2-3] . 

Students  in  an  introductory  software 
engineering  course  were  required  to  use 
Karner’s  UCP  method  to  estimate  the 
overall  effort  required  to  implement  a  sim¬ 
ple  hotel  reservation  system.  An  overview 
of  the  team  project  is  presented,  followed 
by  a  step-by-step  review  of  the  UCP 


method.  The  PFs  achieved  by  the  student 
teams  are  determined  using  the  UCP  esti¬ 
mates  and  time  sheet  data,  and  sources  of 
discrepancies  in  the  estimates  are  ana¬ 
lyzed.  Finally,  the  lessons  learned  from 
this  experience  are  summarized. 

Team  Project  Requirements 

Six,  four-person  student  teams  were  each 
given  one  semester  to  implement  a  sim¬ 
plified  hotel  reservation  system  in  C+  + 
using  a  common  set  of  initial  require¬ 
ments.  The  hotel  reservation  system  was 
to  allow  hotel  employees  to  make  reser¬ 
vations  for  customers  and  to  generate 
reports  that  summarized  the  current  state 
of  the  hotel’s  room  reservations.  The 
base  rate  charged  for  each  hotel  room 
would  be  set  in  advance  and  could  be 
changed  to  reflect  variations  in  demand 
throughout  the  year.  The  actual  rate 
charged,  however,  could  vary  depending 
upon  which  of  the  four  types  of  reserva¬ 
tions  (prepaid,  advance,  conventional,  or 
incentive)  was  selected.  The  reservation 
system  also  had  to  apply  specified  penal¬ 
ties  for  no-show  guests.  At  check  out, 
guests  were  to  receive  a  bill  that  summa¬ 
rized  the  details  of  their  reservation  and 
the  total  charges. 

The  reservation  system  was  also 
required  to  maintain  records  of  all  trans¬ 
actions,  including  reservation  changes 
and  cancellations,  and  archive  those 
records  to  disk.  Finally,  employees  were 
to  have  the  option  of  generating  one  of 
the  five  types  of  reports  that  summarized 
various  aspects  of  hotel  operation, 
including  lists  of  expected  arrivals  and 
current  occupancy  lists.  Additional  details 
on  the  hotel  reservation  system  project 
may  be  found  in  Appendix  A  of  [3]. 

Teams  were  required  to  practice 
object-oriented  analysis  and  design  tech¬ 
niques  learned  in  the  course.  Given  the 
time  constraints  of  the  semester,  a  graph¬ 
ical  user  interface  for  the  reservation  sys¬ 
tem  was  optional.  All  teams  were 
required  to  follow  an  iterative  and  incre¬ 
mental  development  process  based  upon 


the  five  core  disciplines  of  the  Unified 
Process  (requirements,  analysis,  design, 
implementation,  and  test).  During  the 
project,  teams  were  required  to  generate 
and  refine  seven  different  deliverables  as 
follows: 

•  Software  Project  Management  Plan. 

•  Use  Case  Model. 

•  Unified  Modeling  Language  (UML) 
Class  Diagrams. 

•  UML  Sequence  Diagrams. 

•  Test  and  Integration  Plan. 

•  C++  Source  Code  and  Makefile. 

•  User  Manual. 

Five  intermediate  milestones  were 
established  to  encourage  teams  to  start 
the  project  early  and  avoid  the  last  minute 
heroic  efforts  at  the  end  of  the  semester. 
At  each  milestone,  teams  were  also 
required  to  submit  timesheets  that  sum¬ 
marized  the  total  time  spent  by  each  team 
member  on  the  submitted  artifacts  at  that 
milestone.  This  data  on  actual  effort 
would  later  be  used  to  compute  the  PF 
for  each  team. 

I  first  came  across  the  UCP  estima¬ 
tion  method  in  [2]  as  the  teams  were 
nearing  completion  of  their  Use  Case 
models.  Since  my  previous  software  esti¬ 
mation  experience  utilized  line-of-code 
(LOC)  based  methods,  I  added  a  UCP 
estimate  requirement  to  the  team  project 
to  see  how  well  this  estimation  technique 
would  work,  especially  since  all  six  teams 
would  be  producing  estimates  for  the 
same  product.  Students  were  asked  to  use 
their  existing  use  case  model,  as  is,  when 
completing  the  UCP  estimate. 

Brief  Review  of  the  UCP 
Method 

This  overview  of  the  UCP  estimation 
method  is  derived  from  [1,2].  Included  in 
the  discussion  is  an  example  UCP  calcula¬ 
tion,  utilizing  values  reported  by  one  of 
the  student  teams.  Following  this  review 
of  the  UCP  method,  the  estimates  pre¬ 
pared  by  the  six  student  teams  are  pre¬ 
sented  and  analyzed. 
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Use  Case 
Category 

Category  Description 

Category 

Weight 

Transactions  T  per 

Use  Case 

Objects  Required  for 
Implementation  R 

Simple 

T  <  4 

R  <  5 

5 

Average 

4  <  T  <  7 

5<R<  10 

10 

Complex 

T  >  7 

R>  10 

15 

Table  1 :  Use  Cases  Complexity  Categories  and  Weights  [1  -2] 


Actor 

Category 

Category  Description 

Category 

Weight 

Simple 

Actor  represents  another  system  interacting  through  a  defined 
application  programming  interface 

1 

Average 

An  actor  which  represents  interaction  with  another  system  via 
a  protocol  or  human  interaction  through  a  text  interface 

2 

Complex 

An  actor  which  interacts  through  a  graphical  user  interface 

3 

Table  2:  Actor  Complexity  Categories  and  Weights  [1-2] 


Step  I:  Unadjusted  Use  Case  Weight 

Starting  with  the  use  case  model,  the  first 
step  in  the  UCP  estimation  method  is  to 
calculate  the  Unadjusted  Use  Case  Weight 
(UUCW),  which  is  a  weighted  sum  of  the 
total  number  of  steps  identified  in  all  of 
the  use  cases.  The  use  cases  are  sorted 
into  three  different  categories  (Simple, 
Average,  or  Complex)  depending  upon 
the  number  of  steps  (or  transactions) 
identified  or  the  perceived  complexity  of 
implementation  (estimated  number  of 
objects  required).  Table  1  describes  the 
use  case  category  criteria. 

Consider  the  data  reported  by  Team 
A.  Team  A  identified  a  total  of  14  use 
cases  for  the  team  project.  Seven  of  these 
use  cases  were  determined  to  be  Simple  in 
that  the  use  cases  consist  of  three  or 
fewer  transactions,  and  seven  were  con¬ 
sidered  to  be  Average  in  that  they  consist¬ 
ed  of  four  to  seven  transactions.  Team  A 
identified  no  Complex  use  cases.  Thus,  the 
weighted  sum  UUCW  for  Team  A  is  com¬ 
puted  as  follows: 

Team  A  UUCW  =  7*5  +  7*10  +  0* 
15  =  105 

Step  2:  Unadjusted  Actor  Weight 

As  with  the  use  cases,  the  actors  are  also 
categorized  by  their  perceived  complexity 
(Simple,  Average,  or  Complex).  The 
Unadjusted  Actor  Weight  (UAW)  is  a 
weighted  sum  of  all  actors  appearing  in 
the  use  case  model.  Table  2  summarizes 
the  actor  category  criteria  and  category 
weights.  Team  A  reported  a  single 
Complex  actor  in  their  use  case  model 
and  no  Simple  or  Average  actors.  The 
weighted  sum  UAW  for  Team  A  is  calcu¬ 
lated  as  follows: 

Team  A  UAW  =  0  *  1  +  0  *  2  +  1  * 

3  =  3 

Step  3:  Unadjusted  UCP 

The  Unadjusted  UCP  (UUCP)  is  comput¬ 
ed  as  the  sum  of  the  UUCW  and  the 
UAW.  For  Team  A,  the  UUCP  is  comput¬ 
ed  as  follows: 

Team  A  UUCP  =  UUCW  +  UAW  = 
105  +  3  =  108 

Step  4:Technical  Complexity  Factor 

The  Technical  Complexity  Factor  (TCF) 
is  used  to  adjust  the  UCP  estimate  based 
upon  the  perceived  technical  complexities 
of  the  project.  The  influences  of  13  tech¬ 
nical  factors  on  the  development  effort 
are  estimated  using  a  scale  from  0  (irrele¬ 
vant)  to  5  (essential)  with  the  value  3  used 
if  the  factor’s  influence  is  unknown.  The 


technical  factors  and  their  relative  weights 
are  described  in  Table  3.  For  each  techni¬ 
cal  factor,  the  influence  estimate  is  multi¬ 
plied  by  the  corresponding  factor  weight 
and  summed  across  all  thirteen  factors  to 
compute  the  Technical  Total  Factor 


(TTF).  The  TCF  is  computed  from  the 
TTF  as  follows: 

TCF  =  0.60  +  0.01  *  TTF 

Using  Team  As  influence  estimates  as 


Table  3:  Technical  factors  that  influence  complexity  as  described  in  [1,  2]  along  with  their  relative 
weights.  Also  included  are  influence  estimates  of  each  factor  made  by  Team  A.  Influence  estimates 
range  from  0  (irrelevant)  to  5  (essential). 


Technical 

Factor 

Factor  Description 

Factor 

Weight 

Team  A 

Influence 

Estimates 

Ti 

Distributed  systems 

2 

0 

t2 

Response  time  or  throughput  performance 

1 

4 

t3 

End  user  efficiency 

1 

3 

t4 

Complex  internal  processing 

1 

2 

t5 

Reusability  of  code  in  other  applications 

1 

0 

t6 

Ease  of  installation 

0.5 

4 

t7 

Ease  of  use 

0.5 

4 

Ts 

Portability 

2 

0 

t9 

Changeability 

1 

3 

Tio 

Concurrency 

1 

0 

Tii 

Special  security  features 

1 

0 

Tl2 

Provide  direct  access  for  third  parties 

1 

0 

Ti3 

Special  user  training  facilities 

1 

2 

Table  4:  environmental factors  that  influence  complexity  as  described  in  [1-2]  along  with  their  rela¬ 
tive  weights.  Also  included  are  influence  estimates  of  each  factor  made  by  Team  A.  Influence  estimates 
range  from  0  (irrelevant)  to  5  (essential). 


Environmental 

Factor 

Factor  Description 

Factor 

Weight 

Team  A 

Influence 

Estimates 

Ei 

Familiarity  with  Unified  Process* 

1.5 

1 

e2 

Part  time  workers 

-1 

4 

e3 

Analyst  capability 

0.5 

1 

e4 

Application  experience 

0.5 

1 

e5 

Object-oriented  experience 

1 

3 

Ee 

Motivation 

1 

4 

e7 

Difficult  programming  language 

-1 

0 

e8 

Stable  requirements 

2 

3 

*changed  from  original  term  Objectory 


www.stsc.hill.af.mil  9 


March  2008 


The  Beginning 


Project 

Number  of  Actors 
(complexity) 

Number  of  Use  Cases 
(complexity) 

TCF 

ECF 

UCPs 

Person-Hours 

Required 

PF 

(Hours  per  UCP) 

A 

5  (average) 

10  (average) 

1.00 

0.975 

107.25 

2150 

20.05 

B 

5  (average) 

50  (average) 

1.00 

1.175 

599.25 

12500 

20.86 

C 

5  (average) 

15  (average) 

1.00 

1.175 

188.00 

5400 

28.72 

Table  5:  Project  Metrics  Used  by  Karner  to  Determine  PF  [1] 


shown  in  Table  3,  Team  A  computed  a 
TTF  of  18  resulting  in  a  0.78  TCF. 

Step  5:  Environmental  Complexity 
Factor 

The  Environmental  Complexity  Factor 
(ECF)  is  used  to  adjust  the  estimate  for 
people-related  factors  such  as  skill  levels, 
experience,  motivation,  etc.  The  influ¬ 
ences  of  eight  environmental  factors  on 
the  development  effort  are  estimated 
using  a  scale  from  0  (irrelevant)  to  5 
(essential)  with  the  value  3  used  if  the 
factor’s  influence  is  unknown.  Table  4 
(see  previous  page)  lists  the  UCP  envi¬ 
ronmental  factors,  their  relative  weights, 
and  their  estimated  impact  according  to 
Team  A.  For  each  environmental  factor, 
the  influence  estimate  is  multiplied  by  the 
corresponding  factor  weight  and 
summed  across  all  eight  factors  to  com¬ 
pute  the  Environmental  Total  Factor 
(ETF).  The  ECF  is  computed  from  the 
ETF  using  the  following  equation: 

ECF  =  1.4-0.03*  ETF 

Using  Team  As  influence  estimates  as 
shown  in  Table  4,  Team  A  computed  an 
ETF  of  11.5  resulting  in  a  1.06 
Environmental  Complexity  Factor. 

Step  6:  Compute  UCPs  and 
Estimated  Labor 

The  UCP  estimate  for  the  product  is  com¬ 
puted  as  the  product  of  the  initial  unad¬ 
justed  use  case  points,  the  TCF,  and  the 
ECF.  For  Team  A,  the  UCP  computation 
is  summarized  next: 

Team  A  UCP  =  UUCP  *  TCF  *  ECF  = 
108*0.78*  1.06  =  89 

The  Estimated  Labor  is  the  product  of 
the  UCP  estimate  and  an  experimentally 
determined  PF.  For  the  three  products 
presented  by  Karner  in  [1],  the  PF  was 


experimentally  determined  to  be  in  the 
range  of  20-30  person-hours  per  use  case 
point  as  shown  in  Table  5.  Fitting  a 
straight  line  to  this  data,  Karner  comput¬ 
ed  a  nominal  productivity  of  20  person- 
hours  per  use  case  point. 

In  practice,  there  are  a  number  of  dif¬ 
ferent  methods  that  one  might  use  to 
determine  a  PF.  One  could  use  UCP  PFs 
documented  in  the  software  engineering 
literature.  These  values,  however,  may  not 
produce  an  accurate  estimate  since  they  do 
not  necessarily  reflect  the  types  of  systems 
you  are  developing,  the  programming  lan¬ 
guages  or  development  tools  that  you  will 
be  using,  etc.  Another  approach  would  be 
to  utilize  your  own  organization’s  project 
metrics  to  calculate  a  PF.  An  advantage  of 
this  approach  is  that  these  metrics  would 
account  for  your  particular  organization’s 
software  development  process.  Another 
advantage  is  that  you  could  selectively 
include  metrics  from  relevant  projects 
only. 

Having  no  experimental  data  on  stu¬ 
dent  teams  using  this  method  for  a  semes¬ 
ter-sized  student  project,  students  were 
asked  to  complete  their  estimates  using 
the  nominal  value  of  20  person-hours  per 
use  case  point  to  demonstrate  that  they 
understood  the  mechanics  of  the  calcula¬ 
tion.  Students  were  warned  that  this  would 
likely  result  in  an  overestimate  of  the  actu¬ 
al  labor  required  on  the  assigned  project 
since  Karner’s  nominal  productivity  was 
derived  from  data  collected  from  larger 
commercial  products.  I  planned  to  use  this 
first  classroom  experience  with  UCP  esti¬ 
mation  to  gather  metrics  that  I  might  use 
to  compute  a  more  realistic  PF  for  subse¬ 
quent  classroom  use.  My  goal  was  that 
each  student  would  need  to  average  at 
minimum  five  hours  per  person  per  week 
to  satisfactorily  complete  the  team  soft¬ 
ware  project.  Assuming  four  students  per 
team  working  12  weeks  at  five  hours  per 
person  per  week,  my  nominal  labor  goal 


was  240  hours  total  per  team.  The  calen¬ 
dar  spacing  of  the  milestones  was  intend¬ 
ed  to  force  the  students  to  distribute  this 
labor  uniformly  across  the  span  of  the 
project. 

Student  UCP  Estimates 

The  UCP  estimates  prepared  by  the  stu¬ 
dent  teams  are  summarized  in  Table  6 
along  with  reported  labor  hours  required 
to  complete  the  project.  Even  though  all 
teams  were  estimating  the  same  project 
starting  with  the  same  initial  list  of 
requirements,  a  wide  range  of  UCP  esti¬ 
mates  were  produced  with  the  largest  esti¬ 
mate  of  275  UCPs  being  approximately 
five  times  larger  than  the  smallest  estimate 
of  56  UCPs.  Reported  effort  also  varied 
over  a  wide  range  from  a  low  of  170  hours 
to  a  high  of  384  hours.  Calculated  pro¬ 
ductivities  ranged  from  0.62  to  3.89  hours 
per  use  case  point,  which  is  significantly 
lower  than  Karner’s  nominal  value.  To 
determine  the  source  of  the  discrepancies, 
we  examine  the  intermediate  calculations 
below. 

Analysis  of  Estimate 
Discrepancies 

Table  7  summarizes  the  intermediate  UCP 
calculations  for  all  six  teams.  The  subse¬ 
quent  discrepancy  analysis  examines  the 
UCP  calculations  and  identifies  factors 
that  contributed  to  the  observed  varia¬ 
tions  across  the  student  teams. 
Recommendations  for  improving  the  con¬ 
sistency  and  quality  of  the  estimates  are 
also  presented. 

UUCW  Calculations 

The  majority  of  teams  identified  between 
nine  and  14  distinct  use  cases  though 
Team  B  and  Team  D  identified  1 8  and  32 
use  cases  respectively.  The  primary  source 
of  discrepancy  in  the  number  of  use  cases 
identified  was  the  consolidation  or  expan¬ 
sion  of  related  use  cases,  that  is,  a  use  case 
with  multiple  scenarios  may  have  been 
split  and  counted  as  multiple  distinct  uses 
cases.  An  example  of  this  would  be  the 
Reserve  Room  use  case  where  each  of  the 
four  types  of  room  reservations  is  treated 
as  a  separate  use  case.  Splitting  of  such  a 
use  case  could  inflate  the  UUCW  if  the 
complexity  of  the  resulting  use  cases  did 
not  decrease.  Team  D’s  estimate  is  an 


Table  6:  Summary  of  Team  UCP  Estimates ■  Reported  Effort,  and  PF 


Student  Team 

Project  Data 

Student  Teams 

Mean  All 
Teams 

A 

B 

C 

D 

E 

F 

UCP  Estimates 

89 

74 

56 

275 

53 

123 

111.6 

Reported  Effort  (hours) 

297 

262 

216 

170 

171 

384 

249.7 

Actual  PF 
(hours/UCP) 

3.34 

3.52 

3.89 

0.62 

3.22 

3.12 

2.95 
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extreme  example  of  this  situation. 

Another  source  of  UUCW  discrepan¬ 
cy  is  in  the  number  of  actor-product  inter¬ 
actions  identified.  Some  teams  described 
additional  interactions  for  a  given  use  case 
than  did  other  teams  due  to  either  an  alter¬ 
nate  interpretation  of  the  initial  project 
requirements  or  feature  creep,  the  incor¬ 
poration  of  extra  features  by  the  develop¬ 
ers.  For  example,  one  team  included  a  user 
authentication  interchange  with  every  use 
case.  Other  teams  included  confirmation 
interchanges  to  verify  user  inputs.  In  other 
instances,  a  team  would  split  an  interac¬ 
tion  into  multiple  interchanges.  For  exam¬ 
ple,  the  hotel  manager  should  be  able  to 
set  the  base  room  rate  on  a  given  date. 
Some  teams  documented  the  two  inputs, 
base  rate  and  date,  as  a  single  use  case  step 
while  other  teams  split  the  input  of  the 
two  values  into  multiple  steps. 

It  was  also  clear  that  on  some  teams, 
no  effort  was  made  to  make  the  level  of 
use  case  detail  included  uniform  across  the 
entire  use  case  model.  Instead,  use  cases 
were  assigned  to  individual  team  members 
and  prepared  as  individual  assignments 
with  little  or  no  peer  review.  Since  the 
UUCW  is  a  measure  of  the  number  of 
steps  or  interactions  between  an  actor  and 
the  system,  additional  interactions  can 
result  in  a  given  use  case  being  classified  as 
more  complex  during  the  UCP  estimation 
process,  inflating  the  UUCW. 

The  first  step  in  determining  a  reason¬ 
able  UUCW  estimate  must  be  communica¬ 
tion  with  the  customer.  The  use  case  model 
documents  the  developer’s  vision  of  the 
product’s  functionality,  yet  I,  acting  as  the 
customer,  received  surprisingly  few  ques¬ 
tions  from  the  students  regarding  clarifica¬ 
tion  of  specific  project  requirements. 
Students  developed  their  products  in  a 
vacuum,  by  choice,  and  as  a  result  the 
teams  were  not  really  estimating  the  exact 
same  product  due  to  their  respective  inter¬ 
pretations  of  the  initial  requirements  and 
occasional  addition  of  nice-to-have  features 
that  were  not  explicitly  required. 

A  use  case  preparation  standard  could  also 
improve  the  UUCW  estimation  proce¬ 
dure.  Such  a  standard  should  include  spe¬ 
cific  criteria  for  combining  or  splitting  of 
use  cases  for  estimation  purposes. 
Examples  must  be  included  in  the  stan¬ 
dard  to  illustrate  the  desired  level  of  detail 
to  include  in  the  model  for  estimation  pur¬ 
poses.  This  level  of  detail  is  likely  to  vary 
with  the  scope  of  the  product  under  con¬ 
sideration  and  is  an  area  of  research  that  I 
am  currently  pursuing. 

One  should  also  perform  a  reality  check  on 
the  initial  UUCW  estimate  derived  from  the 
use  case  model.  Karner’s  UCP  method 


allows  you  to  determine  the  complexity  of 
a  use  case  from  its  text  description,  but  as 
shown  in  Table  1,  he  also  specified  for 
each  complexity  category  the  number  of 
objects  required  for  implementation  [1]. 
As  a  reality  check,  one  can  revisit  the  ini¬ 
tial  complexity  assessment  of  each  use 
case  by  examining  the  number  of  objects 
required  in  its  implementation.  If  the  two 
assessments  disagree,  you  will  have  to 
make  some  decisions  as  to  how  to  pro¬ 
ceed.  The  brief  summary  of  Karner’s  esti¬ 
mation  technique  presented  in  [1]  pro- 

“Some  students  felt  it 
was  easiest  to  rate  a 
product  for  a  particular 
factor  if  it  happened  to 
fall  at  one  of  the 
extremes,  irrelevant, 
essential,  or  unknown, 
but  they  expressed  a 
need  for  some  criteria  to 
differentiate  the 
intermediate  influence 
levels” 

vides  no  guidance  on  how  to  deal  with  this 
discrepancy.  One  approach  would  be  to 
complete  the  calculation  under  the  worst- 
case  assumption,  always  sorting  use  cases 
into  the  most  complex  category  identified 
by  either  of  the  two  methods.  One  could 
also  average  the  complexity  weights  indi¬ 
cated  for  those  use  cases  in  which  the  two 
methods  produced  different  complexity 
assessments.  You  could  also  compare  your 
UUCW  estimate  to  that  for  any  similar 
products  developed  by  your  organization 
to  see  if  it  seems  reasonable. 


UAW  Calculations 

Two  types  of  errors  were  observed  in  the 
student  UAW  calculations:  incorrect  identi¬ 
fication  of  the  set  of  actors,  and  duplicate 
counting  of  actors  in  the  calculation.  In  my 
view,  the  system  had  two  actors,  a  hotel 
employee  and  a  hotel  manager,  who  direct¬ 
ly  interacted  with  the  reservation  system, 
and  a  Guest,  who  interacted  indirectly  with 
the  system  via  the  hotel  employee  or  man¬ 
ager.  Team  B  argued  that  the  guest  could  be 
omitted  for  estimation  purposes  since  the 
guest  did  not  directly  interact  with  the 
reservation  system.  Team  C  included  all 
three  actors  in  their  estimate.  Team  A  iden¬ 
tified  a  single  actor  but  classified  that  actor 
as  complex  since  they  implemented  a 
graphical  user  interface.  While  inexperience 
at  use  case  modeling  contributed  to  these 
discrepancies,  additional  guidance  was 
needed  on  the  inclusion  or  exclusion  of 
indirect  actors  in  the  estimate.  Teams  D-F, 
however,  counted  the  same  actor  multiple 
times  for  each  use  case  in  which  that  actor 
was  involved,  inflating  their  resulting  UAW. 
Several  commercial  and  freeware  UCP  esti¬ 
mation  software  tools  have  reduced  the 
possibility  of  this  particular  error  by  the 
way  their  developers  have  chosen  to  guide 
users  through  the  UCP  estimation  process. 

TCP  and  ECF  Calculations 

Both  the  TCF  and  ECF  calculations  evalu¬ 
ate  to  approximately  1 .0  if  the  influence  of 
all  of  their  corresponding  factors  are 
unknown.  Recall  that  the  influence  values 
are  integers  that  range  from  0  (irrelevant) 
to  5  (essential)  with  an  influence  value  of  3 
used  to  indicate  that  the  impact  of  a  par¬ 
ticular  technical  or  environmental  factor  is 
unknown.  Some  students  felt  it  was  easiest 
to  rate  a  product  for  a  particular  factor  if  it 
happened  to  fall  at  one  of  the  extremes , 
irrelevant ,  essential \  or  unknown ,  but  they 
expressed  a  need  for  some  criteria  to  dif¬ 
ferentiate  the  intermediate  influence  levels. 

Fortunately,  the  TCF  proved  to  be  rel¬ 
atively  insensitive  to  variations  on  the  per¬ 
ceived  impact  of  a  single  technical  factor 
since  the  weights  associated  with  each  fac¬ 
tor  are  small.  The  computed  TCFs  were 
all  within  0.08  of  the  overall  mean  value 
0.79.  Some  variation  in  ECF  is  to  be 


Table  7:  Summary  of  Supporting  UCP  Estimate  Calculations 


Metric 

Student  Team  Estimates 

Mean  All 
Teams 

A 

B 

C 

D 

E 

F 

Total  Use  Cases 

14 

18 

12 

32 

9 

14 

16.5 

UUCW 

105 

120 

70 

310 

90 

160 

142.5 

Total  Actors 

1 

2 

3 

10 

9 

14 

6.5 

UAW 

3 

6 

6 

18 

18 

28 

13.17 

TCF 

0.78 

0.71 

0.80 

0.87 

0.72 

0.87 

0.79 

ECF 

1.06 

0.83 

0.92 

0.97 

0.68 

0.76 

0.87 
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expected  since  the  ECF  gauges  people- 
related  factors  such  as  object-oriented 
development  experience,  application 
domain  experience,  motivation,  etc. 

PF  Calculations 

The  average  productivity,  excluding  Team 
D,  was  approximately  3.5  hours  per  use 
case  point,  which  was  significantly  lower 
than  Karner’s  nominal  value  of  20  hours 
per  use  case  point.  Karner’s  nominal  value 
was  determined  from  real-world  products, 
which  are  likely  to  be  significantly  larger 
and  more  robust  than  those  developed  by 
the  student  teams  (see  reported  labor  in 
Table  5).  Given  the  time  constraints  of  the 
semester,  the  student  products  are  essen¬ 
tially  prototypes  that  lack  adequate  error 
handling,  and  in  some  cases,  omit  function¬ 
ality  identified  in  their  use  case  model. 

It  is  also  important  to  remember  that 
these  PFs  are  derived  from  the  labor  hours 
reported  by  the  student  teams.  Inaccurate 
reporting  of  labor  hours  on  student  pro¬ 
jects  does  occur.  In  some  cases,  students 
forget  to  record  their  hours  for  the  week 
and  report  an  estimated  labor  value  for  that 
week.  Students  may  also  choose  to  inflate 
their  reported  hours  in  hopes  of  achieving 
a  better  grade  on  the  assignment. 

Mathematical  Errors 

While  the  mathematical  computations 
required  by  the  UCP  estimation  method 
are  not  conceptually  difficult,  errors  did 
occur.  The  best  way  to  minimize  such 
errors  is  to  provide  a  software  tool  that  imple¬ 
ments  the  UCP  calculations  correctly. 
While  a  spreadsheet  estimation  template 
would  suffice,  a  dedicated  UCP  estimation 
tool  that  interfaced  with  your  modeling 
tool  would  help  prevent  errors  in  execu¬ 
tion  of  the  estimation  method  itself,  such 
as  duplicate  counting  of  actors  in  the 
UAW  calculation,  in  addition  to  preventing 
the  purely  numeric  errors. 

Conclusions 

The  student  team  estimation  data  illustrates 
both  the  potential  of  the  UCPs  estimation 
method  and  some  of  the  pitfalls  that  can  be 
avoided.  Excluding  Teams  D-F  due  to  cal¬ 
culation  errors,  team  productivity  averaged 
approximately  3.5  hours  per  use  case  point 
on  this  semester-sized,  four-person  project. 
While  this  was  significantly  lower  than  that 
reported  by  Karner  [1],  the  time  constraints 
of  the  semester  prevent  the  students  from 
developing  product-quality  code. 

Since  the  PF  is  determined  experimen¬ 
tally,  it  is  important  to  have  a  consistent 
method  of  producing  a  use  case  points  esti¬ 
mate.  The  consistency  of  the  presented 
estimates  could  have  been  improved  by  bet¬ 


ter  communication  with  the  customer, ;  to  prevent 
inclusion  of  unnecessary  features,  and  by 
the  use  of  a  use  case  preparation  standard.  Such 
a  standard  must  address  the  level  of  detail 
to  be  included  in  the  description  of  each 
use  case  and  include  specific  criteria  for 
splitting  or  combining  use  cases. 
Commercial  UCP  software  tools  also  help  to 
prevent  errors  by  automating  many  of  the 
UCP  calculations.  One  must  also  perform  a 
reality  check  on  any  UCP  estimate,  using 
either  the  required  objects  count  of  the 
UCP  method,  a  best-case/worst-case  analy¬ 
sis,  or  your  own  historical  data,  to  deter¬ 
mine  if  the  method  has  produced  a  reason¬ 
able  estimate.  Finally,  one  must  keep  in 
mind  that  the  UCP  estimation  method  is 
the  focus  of  ongoing  research  worldwide 
so  your  estimation  procedures  should  be 
reviewed  periodically  to  incorporate  the  lat¬ 
est  lessons  learned.^ 
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Good  Practices  for  Developing  User  Requirements 
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Defining  user  requirements  —  the  needs  of  the  stakeholders  who  directly  interact  with  the  system  —  is  arguably  one  of  the  most  dif¬ 
ficult  challenges  in  building  complex  systems.  When  it  comes  to  defining  user  requirements  for  software ,  it  is  essential  to  use  models 
to  document  and  analyse  the  requirements.  This  article  provides  a  requirements  model  roadmap  that  helps  software  development 
teams  understand  the  effective  use  of  requirements  models.  It  also  describes  good practices  for  creating  and  using  these  models. 


Many  software  developers  have  a  love- 
hate  relationship  with  requirements. 
They  love  having  a  list  of  things  they  need 
to  engineer  into  the  product  they  are 
building,  but  they  hate  it  when  the  require¬ 
ments  are  unclear,  inaccurate,  self-contra¬ 
dictory,  or  incomplete.  They  are  right  to 
be  concerned. 

The  price  is  high  for  teams  that  fail  to 
define  requirements  or  that  do  it  poorly. 
Ill-defined  requirements  result  in  require¬ 
ments  defects,  and  the  consequences  of 
these  defects  are  ugly  [1-  6]: 

•  Expensive  rework  and  cost  overruns. 

•  A  poor  quality  product. 

•  Late  delivery. 

•  Dissatisfied  customers. 

•  Exhausted  and  demoralized  team 
members. 

To  reduce  the  risk  of  software  project 
failure  and  the  costs  associated  with  defec¬ 
tive  requirements,  project  teams  must 
address  requirements  early  in  software 
development  and  they  must  define 
requirements  properly. 

A  Short  Review  of 
Requirements 

Before  we  get  to  the  nitty-gritty  of  build¬ 
ing  requirements  models,  let  us  look  at 
some  basic  requirements  concepts.  User 
requirements  —  the  focus  of  this  article  — 
are  one  of  three  types  of  requirements 
(see  Figure  1).  The  other  two  types  are 
those  related  to  the  mission  or  business 
and  those  that  describe  the  software  itself. 

Business  requirements  are  statements  of 
the  business  rationale  for  the  project. 
These  requirements  grow  out  of  the 
vision  for  the  product  which,  in  turn,  is 
driven  by  mission  (or  business)  goals  and 
objectives.  The  product’s  vision  statement 
articulates  a  long-term  view  of  what  the 
product  will  accomplish  for  its  users.  It 
should  include  a  statement  of  scope  to 
clarify  which  capabilities  are  and  are  not  to 
be  provided  by  the  product. 

User  requirements  define  the  software 
requirements  from  the  user’s  point  of 
view,  describing  the  tasks  users  need  to 
accomplish  with  the  product  and  the  qual¬ 


ity  requirements  of  the  software  from  the 
user’s  point  of  view.  Users  can  be  broadly 
defined  to  include  not  only  the  people 
who  access  the  system  but  also  inanimate 
users  such  as  hardware  devices,  databases, 
and  other  systems.  In  the  systems  pro¬ 
duced  by  most  government  organizations, 
user  requirements  are  articulated  in  their 
concept  of  operations  document. 

Software  requirements  are  detailed 
descriptions  of  all  the  functional  and  non¬ 
functional  requirements  the  software  must 
fulfill  to  meet  business  and  user  needs. 
Nonfunctional  requirements  include  soft¬ 
ware  design  constraints,  external  inter¬ 
faces,  and  quality  attributes  such  as  per¬ 
formance,  security,  installation  ability, 
availability,  safety,  reusability,  and  more  [7]. 
Software  requirements,  which  are  docu¬ 
mented  in  a  software  requirements  specifi¬ 
cation,  establish  an  agreement  between 
technical  specialists  and  business  man¬ 
agers  on  what  the  product  must  do. 


The  key  activities  in  requirements 
development  are  the  following:  elicitation , 
analysis,  specification ,  and  validation  [8].  In 
elicitation ,  you  identify  the  sources  of 
requirements  and  solicit  requirements 
from  those  sources.  Requirements  elicita¬ 
tion  relies  on  appropriate  stakeholder 
involvement,  one  of  the  most  critical  ele¬ 
ments  for  project  success  [9].  The  goal  of 
requirements  analysis  is  to  sufficiently 
understand  and  define  the  requirements 
so  that  stakeholders  can  prioritize  and 
allocate  them  to  software.  Specification 
involves  differentiating  and  documenting 
functional  and  nonfunctional  require¬ 
ments  and  checking  that  the  requirements 
are  documented  unambiguously  and  com¬ 
pletely.  1 Validation  examines  the  require¬ 
ments  to  ensure  that  they  satisfy  user’s 
needs. 

Elicitation  and  analysis  are  crucial  early 
activities  that  require  intense  stakeholder 
involvement.  To  analyze  the  requirements 


Figure  1 :  Requirements  Levels 
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you  are  eliciting,  a  key  good  practice  is  to 
create  requirements  models  (also  referred  to 
as  analysis  models ):  user  requirements  repre¬ 
sented  by  text  (such  as  tables,  lists,  or 
matrices),  diagrams,  or  a  combination  of 
text  and  graphical  material  [7].  These 
models  facilitate  communications  about 
requirements  with  your  stakeholders. 

As  you  elicit  requirements  from  stake¬ 
holders  and  represent  them  using  require¬ 
ments  models,  you  should  verify  your 
models  to  ensure  they  are  internally  con¬ 
sistent.  You  also  need  to  prioritize  your 
requirements:  With  active  user  involve¬ 
ment,  you  analyze  the  trade-offs  among 
requirements  to  establish  their  relative 
importance  [8]. 

The  User  Requirements 
Model  Roadmap 

Now  let  us  take  a  closer  look  at  user 
requirements  models.  The  beauty  of  the 
Requirements  Model  Road  Map  (Figure  2) 
is  that  it  shows  the  relationships  between 
the  three  types  of  requirements  (business, 
user,  and  software)  and  categorizes  the 
models  you  can  use  to  represent  each  type. 
Each  model  is  designed  to  answer  one  of 
the  5Ws  +  1H  questions:  Who?  What? 
When?  Why?  How?  [7]. 

(Note  that  the  question  Where?  pro¬ 
vides  information  mainly  about  nonfunc¬ 
tional  requirements.  Although  these  are 
not  user  requirements  -  which  depict 
functional  requirements  —  analysts  asking 
Where?  during  analysis  will  also  discover  a 
slice  of  useful  quality  attributes  such  as 
performance  and  usability). 

In  addition,  the  user  requirements 
model  falls  into  three  categories:  scope, 
high-level  and  detailed,  and  alternative 
models.  Some  models  (shown  in  italics  in 


Figure  2)  are  useful  for  analyzing  the  busi¬ 
ness  process,  and  others  are  useful  for 
clarifying  project  scope.  Defining  stake¬ 
holder  categories  early  in  elicitation,  for 
example,  identifies  the  people  you  should 
involve  in  requirements  modeling.  High- 
level  and  detailed  models,  such  as  use 
cases,  a  data  model,  and  business  rules, 
can  reveal  requirements  defects  such  as 
errors,  omissions,  and  conflicts. 
Requirements  analysts  and  engineers  can 
substitute  alternative  models  when  the 
engineers  better  communicate  require¬ 
ments  or  fit  the  project  culture. 

Each  requirements  model  represents 
information  at  a  different  level  of  abstrac¬ 
tion.  A  model  such  as  a  state  diagram  rep¬ 
resents  information  at  a  high  level  of 
abstraction,  whereas  detailed  textual 
requirements  represent  a  low  level  of 
abstraction.  By  stepping  back  from  the 
trees  (textual  requirements)  to  look  at  the 
forest  (a  state  diagram),  the  team  can  dis¬ 
cover  requirements  defects  not  evident 
when  reviewing  textual  requirements 
alone. 

Because  the  requirements  models  are 
related,  developing  one  model  often  leads 
to  deriving  another.  Examples  of  one 
model  driving  another  model  are  the  fol¬ 
lowing: 

•  Actors  initiate  use  cases. 

•  Scenarios  exemplify  instances  of  use 

cases. 

•  A  use  case  acts  upon  data  depicted  in 

the  data  model. 

•  A  use  case  is  governed  by  business 

rules. 

•  Events  trigger  use  cases. 

In  this  way,  you  can  use  various  routes 
to  harvest  one  model  from  another.  This 
approach  helps  you  develop  the  models 
quickly  while  at  the  same  time  verifying 


the  model’s  completeness  and  correctness. 

User  Requirements  Models 

Here,  in  alphabetical  order,  are  brief 
descriptions  of  the  common  user  require¬ 
ments  models  shown  in  the  User 
Requirements  Models  Road  Map. 

Activity  Diagram 

An  activity  diagram  is  a  model  that  illus¬ 
trates  the  flow  of  complex  use  cases  using 
Unified  Modeling  Language  (UML)  nota¬ 
tion.  This  model  is  useful  for  showing  use 
case  steps  that  have  multiple  extension 
steps,  and  for  visualizing  use  cases. 

Actor  Map 

An  actor  map  is  a  model  that  shows  actor 
interrelationships.  An  actor  map  supple¬ 
ments  the  actor  table  and  can  also  be  used 
as  a  starting  point  for  identifying  use  cases. 
Actors  can  be  written  on  index  cards  (one 
per  index  card)  or  drawn  using  the  UML 
notation.  UML  depicts  actors  in  an  actor 
map  as  stick  figures,  as  boxes  (supplement¬ 
ed  by  the  notation  “<< Actor >>”),  or  as  a 
combination  (e.g.,  stick  figures  for  human 
actors,  and  boxes  for  nonhuman  actors). 

Actor  Table 

An  actor  table  is  a  model  that  identifies  and 
classifies  system  users  in  terms  of  their 
roles  and  responsibilities.  This  model  helps 
reveal  missing  system  users  and  identifies 
functional  requirements  as  user  goals  (use 
cases),  and  also  management  to  clarify  job 
responsibilities. 

Business  Policies 

Business  policies  are  guidelines,  standards, 
and  regulations  that  guide  or  constrain  the 
conduct  of  a  business.  Policies  are  the  basis 
for  the  decision  making  and  knowledge  that 
are  implemented  in  the  software  and  in 
manual  processes.  Whether  imposed  by  an 
outside  agency  or  from  within  the  company, 
policies  are  used  to  streamline  operations, 
increase  customer  satisfaction  and  loyalty, 
reduce  risk,  improve  revenue,  and  adhere  to 
legal  requirements.  This  model  helps  you 
identify  policies  allocated  to  business  peo¬ 
ple,  which  in  turn  allows  management  to 
prepare  for  software  implementation  by 
updating  procedures,  guidelines,  training, 
forms,  and  other  assets  needed  to  enforce 
the  policies.  Some  policies  are  also  allocat¬ 
ed  to  software  for  implementation. 

Business  Rules 

Business  rules  are  text  statements  that 
decompose  business  policies.  Business 
rules  describe  what  defines,  constrains,  or 
enables  the  software  behavior.  You  use 
business  rules  to  specify  the  controls  that 
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govern  user  requirements  and  to  clarify 
which  rules  should  be  enforced  in  software 
and  which  will  be  allocated  to  business 
people.  Because  business  rules  require 
data,  defining  the  rules  will  uncover  need¬ 
ed  data.  User  requirements  depend  on  the 
complete  and  correct  enforcement  of 
business  rules. 

Class  Model 

A  class  model  is  a  diagram  that  shows  the 
classes  to  be  used  in  a  system.  A  class  is  the 
generic  definition  of  a  collection  of  simi¬ 
lar  objects  (persons,  places,  events,  and 
physical  artifacts).  You  use  a  class  model 
in  projects  employing  object-oriented 
software  development  methods,  tools,  or 
databases. 

Context  Diagram 

A  context  diagram  is  a  model  that  shows 
the  system  in  its  environment  with  the 
external  entities  (people  and  systems)  that 
provide  and  receive  information  or  mate¬ 
rials  to  and  from  the  system.  This  model 
helps  stakeholders  to  quickly  and  simply 
define  the  project’s  scope  and  to  focus  on 
what  the  system  needs  as  inputs  and  pro¬ 
vides  as  outputs.  A  context  diagram  helps 
the  team  derive  requirements  models 
(such  as  actors,  use  cases,  and  data  model 
information)  and  can  reveal  possible 
scope  creep  problems  as  new  external 
entities  are  added. 

Data  Dictionary 

A  data  dictionary  is  a  model  that  provides 
a  description  of  the  data  attributes  and 
structures  used  in  a  system.  This  model  is 
a  central  place  for  defining  each  data  ele¬ 
ment  and  describing  its  data  type,  length, 
and  format.  Some  project  teams  use  data 
modeling  tools  that  provide  data  dictio¬ 
nary  capabilities. 

Data  Flow  Diagram  (DFD) 

A  DFD  is  a  model  that  shows  related 
inputs,  processes,  and  outputs  for  process¬ 
es  that  respond  to  external  or  temporal 
events.  Unlike  use  cases  (which  are  orient¬ 
ed  toward  actor  goals),  DFDs  focus  on 
the  data  that  goes  in  and  out  of  each 
process,  taking  an  internal  view  of  how 
the  system  handles  events. 

Data  Model 

A  data  model  shows  the  informational 
needs  of  a  system  by  illustrating  the  logi¬ 
cal  structure  of  data  independent  of  the 
data  design  or  data  storage  mechanism. 
You  use  a  data  model  to  identify,  summa¬ 
rize,  and  formalize  the  data  attributes  and 
structures  needed  to  satisfy  functional 
requirements  and  to  create  an  easy-to- 


maintain  database.  Data  models  help  to 
simplify  design  and  programming  and 
help  identify  external  data  entities  (other 
systems  that  supply  data  to  the  software). 

Data  Table 

A  data  table  is  a  model  in  the  form  of  a 
table  that  contains  sample  data  to  elicit 
and  validate  a  data  model  or  data  dictio¬ 
nary.  Each  row  represents  a  set  of  occur¬ 
rences  in  an  entity,  and  each  column  rep¬ 
resents  sample  attributes. 

Decision  Table 

A  decision  table  is  a  model  that  specifies 
complex  business  rules  concisely  in  an 
easy-to-read  tabular  format.  A  decision 
table  documents  all  the  possible  condi¬ 
tions  and  actions  that  need  to  be  account¬ 
ed  for  in  business  rules.  Conditions  are  fac¬ 
tors,  data  attributes,  or  sets  of  attributes 
and  are  equivalent  to  the  left  side  of  atom¬ 
ic  business  rules.  Actions  are  conclusions, 
decisions,  or  tasks  and  are  equivalent  to 
the  right  side  of  atomic  business  rules. 
Factors  that  must  be  evaluated  form  the 
top  rows  of  the  table.  Actions  make  up 
the  bottom  rows  of  the  table. 

Decision  Tree 

A  graphical  alternative  to  a  decision  table, 
a  decision  tree  presents  conditions  and 
actions  in  sequence.  Each  condition  is 
graphed  with  a  decision  symbol  represent¬ 
ing  jes  or  no  (or  a  true  or  false  conclusion). 
Branches  to  additional  conditions  are 
drawn  left  to  right.  Actions  are  drawn 
inside  rectangles  to  the  right  of  the  branch 
to  which  they  apply. 

Dialog  Hierarchy 

A  dialog  hierarchy  is  a  model  that  shows 
the  dialogs  in  a  system  (or  Web  page)  as  a 
hierarchy.  It  does  not  show  transitions. 

Dialog  Map 

A  dialog  map  is  a  diagram  that  illustrates 
the  architecture  of  a  system’s  user  inter¬ 
face.  It  shows  the  visual  elements  that 
users  manipulate  to  step  through  tasks 
when  interacting  with  the  system.  Dialog 
maps  can  be  used  to  uncover  missing  or 
erroneous  use  case  paths  and  to  validate 
use  cases,  scenarios,  or  both  in  require¬ 
ments  walkthroughs  with  users. 

Event-Response  Table 

An  event-response  table  model  identifies 
each  event  (an  input  stimulus  that  triggers 
the  system  to  carry  out  a  function)  and  the 
event  responses  resulting  from  those 
functions.  An  event-response  table  defines 
the  conditions  to  which  the  system  must 
respond,  thereby  defining  the  functional 


requirements  at  a  scope  level.  (Each  event 
requires  a  predictable  response  from  the 
system.)  This  model  can  also  reveal  needs 
for  external  database  access  or  file  feeds. 

Glossary 

The  glossary  is  a  list  of  definitions  of  busi¬ 
ness  terms  and  concepts  relevant  to  the 
software  being  developed  or  enhanced. 

Persona 

The  persona  is  a  description  of  an  actor 
as  a  fictitious  system  user  or  archetype. 
You  describe  each  persona  as  if  he  or  she 
is  a  real  person  with  personality,  family, 
work  background,  preferences,  behavior 
patterns,  and  personal  attitudes.  The  focus 
is  on  behavior  patterns  rather  than  job 
descriptions.  Each  persona  description  is 
written  as  a  narrative  flow  of  the  person’s 
day  with  added  details  about  personality. 
Four  or  five  personas  represent  the  roles 
that  use  the  system  most  often  or  are 
most  important  to  the  functional  require¬ 
ments. 

Process  Map 

A  process  map  is  a  diagram  that  shows  the 
sequence  of  steps,  inputs,  and  outputs 
needed  to  handle  a  business  process 
across  multiple  functions,  organizations, 
or  job  roles.  This  model  helps  you  identi¬ 
fy  the  processes  that  are  allocated  to  the 
business  (manual  processes)  and  those 
that  will  be  allocated  to  software. 

Prototype 

A  prototype  is  a  partial  or  preliminary  ver¬ 
sion  of  a  system  created  to  explore  or  val¬ 
idate  requirements.  Exploratory  proto¬ 
types  can  be  mock-ups  using  paper,  white¬ 
boards,  or  software  tools. 

Relationship  Map 

A  relationship  map  is  a  diagram  that 
shows  the  information  and  products  that 
are  exchanged  among  external  customers, 
suppliers,  and  key  functions  in  the  organi¬ 
zation.  This  model  helps  you  understand 
the  organizational  context  of  the  project 
by  identifying  affected  business  functions 
and  their  inputs  and  outputs. 

Scenario 

A  scenario  is  a  description  of  a  specific 
occurrence  of  a  path  through  a  use  case 
(i.e.,  a  use  case  instance).  Example:  A  cus¬ 
tomer  calls  to  reschedule  a  job,  adding 
another  service  and  requesting  a  repeat 
customer  discount. 

Stakeholder  Categories 

Stakeholder  categories  are  structured 
arrangements  of  groups  or  individuals 
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who  have  a  vested  interest  in  the  product 
being  developed.  You  use  this  model  to 
understand  who  has  an  interest  in  or  who 
has  influence  on  the  product,  who  will  use 
the  software  and  its  outputs,  and  who  the 
product  will  affect  in  some  way.  These 
groups  and  individuals  will  need  to  be 
kept  informed  about  requirements 
progress,  conflicts,  changes,  and  priorities. 

State-Data  Matrix 

A  state-data  matrix  model  shows  attribut¬ 
es  that  are  added  or  changed  during  a  state 
change.  Each  attribute  is  identified  in  the 
data  model  and  data  dictionary. 

State  Diagram 

A  state  diagram  is  a  visual  representation 
of  the  life  cycle  of  a  data  entity.  Events 
trigger  changes  in  data,  resulting  in  a  new 
state  for  that  entity.  Each  state  is  a  defined 
condition  of  an  entity,  a  hardware  compo¬ 
nent,  or  the  entire  system  that  requires 
data,  rules,  and  actions.  A  state  diagram 
can  also  show  actions  that  occur  in 
response  to  state  changes.  You  use  a  state 
diagram  to  understand  how  events  affect 
data  and  to  identify  missing  requirements 
such  as  events,  business  rules,  data  attrib¬ 
utes,  and  use  case  steps. 

Story 

A  story  is  a  text  description  of  a  path 
through  a  use  case  that  users  typically  doc¬ 
ument.  Stories  replace  use  cases  and  sce¬ 
narios  when  you  are  planning  releases  for 
change-driven  software  projects.  Stories 
are  essentially  detailed  scenarios,  but  each 
story  is  judged  by  developers  to  require 
less  than  two  weeks  to  develop.  When 
combined  with  acceptance  tests,  stories 
are  roughly  equivalent  to  use  cases. 

Use  Case 

The  use  case  describes  in  abstract  terms 
how  actors  use  the  system  to  accomplish 
goals.  Each  use  case  is  a  logical  piece  of 
user  functionality  that  can  be  initiated  by 
an  actor  and  described  from  the  actor’s 
point  of  view  in  a  technology-neutral 
manner.  Use  cases  summarize  a  set  of 
related  scenarios.  The  purpose  of  use 


cases  is  to  reveal  functional  requirements 
by  clarifying  what  users  need  to  accom¬ 
plish  when  interacting  with  the  system. 
Use  cases  are  a  natural  way  to  organize 
functional  requirements  and  can  be  easier 
for  users  to  understand  and  verify  than 
textual  functional  requirements  state¬ 
ments. 

Use  Case  Map 

The  use  case  map  is  a  model  that  illus¬ 
trates  the  work  flow  of  use  cases.  Each 
use  case  map  represents  a  set  of  highly 
cohesive  use  cases  sharing  the  same  data, 
often  triggered  by  the  same  events  or  ini¬ 
tiated  by  the  same  actor. 

Use  Case  Package 

The  use  case  package  is  a  logical,  cohesive 
group  of  use  cases  that  represents  higher 
level  system  functionality.  You  create  a  use 
case  package  by  combining  use  case  maps 
or  grouping  use  cases.  Most  systems  will 
have  multiple  packages.  You  can  use  a 
UML  file  folder  notation  to  show  each 
package,  and  you  can  name  each  package 
according  to  its  functionality. 

Good  Practices  for  Modeling 
User  Requirements 

Following  good  requirements  modeling 
practices  (see  Good  Practices  for  Modeling 
User  Requirements ,  Table  1)  is  the  key  to 
successful  development  of  user  require¬ 
ments.  These  practices  accelerate  model¬ 
ing,  engage  stakeholders,  and  give  you 
high-quality  requirements  —  ones  that  are 
correct,  complete,  clear,  consistent,  and 
relevant. 

The  first  good  practice  is  to  represent 
and  agree  on  the  project’s  scope  early  in 
requirements  elicitation.  Why?  It  has  to  do 
with  scope  creep  —  the  unrestrained 
expansion  of  requirements  as  the  project 
proceeds.  Scope  creep  is  one  of  the  great¬ 
est  risks  in  software  development  [6].  A 
clear  definition  of  product  scope  narrows 
the  project’s  focus  to  enable  better  plan¬ 
ning,  better  use  of  time,  and  better  use  of 
resources.  Moreover,  scope-level  models 
establish  a  common  language  that  team 
members  can  use  to  communicate  about 


the  requirements  and  help  to  articulate  the 
boundary  between  what  is  in  and  what  is 
not  in  scope  for  the  product. 

Another  good  practice,  as  mentioned 
earlier,  is  to  document  your  product  using 
multiple  user  requirements  models.  Each 
model  describes  one  aspect  of  a  problem 
the  product  will  address.  Thus,  no  single 
model  can  describe  all  the  requirements. 
Furthermore,  elements  of  one  model 
often  link  to  elements  of  another,  so  one 
model  can  be  used  to  uncover  related  or 
missing  elements  in  another  model. 

It  is  also  good  to  use  both  text  and 
graphics  to  represent  user  needs.  Multiple 
representations  tap  into  different  modes 
of  human  thinking.  Some  people  think 
more  precisely  with  words,  and  others 
understand  concepts  more  quickly  via  dia¬ 
grams.  Using  both  types  of  representa¬ 
tions  leverages  these  different  thinking 
modes.  In  addition,  mixing  text  and 
graphics  makes  requirements  develop¬ 
ment  more  interesting  and  engaging.  It 
provides  variety  and  permits  stakeholders 
to  understand  their  requirements  from 
more  than  one  angle. 

You  should  also  select  models  that  fit 
the  domain  of  your  product.  That  is 
because  some  models  are  better  suited  to 
communicate  requirements  for  certain 
domains.  For  example,  When  models  (such 
as  an  event-response  table  and  a  state 
machine  diagram)  are  well  suited  to 
dynamic  domains  —  those  that  respond  to 
continually  changing  events  to  store  data 
and  act  on  it  based  on  its  state  at  a  point. 

Another  well-known  good  practice  is 
to  develop  your  requirements  iteratively. 
Each  iteration  is  a  self-contained  mini¬ 
project  in  which  you  undertake  a  set  of 
activities  —  elicitation,  analysis,  specifica¬ 
tion,  and  validation  -  resulting  in  a  subset 
of  requirements.  The  rationale  for  this 
practice  is  that  user  requirements  seldom 
remain  unchanged  for  a  long  period.  On 
teams  using  agile  methods,  each  iteration 
also  incorporates  the  work  needed  to 
deliver  the  working  software  that  satisfies 
those  requirements.  In  some  domains, 
requirements  change  faster  than  the  sys¬ 
tem  or  subsystem  can  be  developed.  In 
addition,  the  cost  of  implementing 
changes  increases  dramatically  as  the  pro¬ 
ject  proceeds.  Developing  requirements  in 
an  evolving  manner  is  essential  in  reducing 
these  risks. 

You  can  also  use  requirements  models 
to  identify  requirements  defects.  The 
interconnections  among  the  models  help 
to  expose  any  inconsistencies  in  related 
models.  This  self-checking  accelerates  the 
team’s  ability  to  uncover  missing,  erro¬ 
neous,  vague,  or  conflicting  requirements. 


Table  1:  Summary:  Good  Practices  for  Modeling  User  Requirements 


1. 

Define,  represent,  and  agree  on  the  project’s  scope  early  in  requirements 
elicitation. 

2. 

Document  your  product  using  multiple  user  requirements  models. 

3. 

Select  models  that  fit  the  domain  of  your  system. 

4. 

Develop  requirements  models  iteratively. 

5. 

Use  requirements  models  to  identify  requirements  defects. 

6. 

Use  models  to  communicate:  Create  simple,  readable  diagrams  focused  less 
on  beauty  and  more  on  understanding. 

7. 

Conduct  retrospectives  as  you  iterate  through  requirements  development. 
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When  you  are  creating  graphical  mod¬ 
els,  it  is  crucial  to  create  simple,  readable 
diagrams.  The  benefit  of  diagrams  is  that 
they  give  you  a  way  to  quickly  communi¬ 
cate  complex,  controversial,  or  unclear 
requirements.  Thus,  you  should  avoid 
complex,  hard-to-read  diagrams.  Draw 
diagrams  manually  to  begin  with  or  use  an 
easy-to-learn  drawing  tool.  Keep  them 
simple  and  easy  to  read.  Focus  on  main¬ 
taining  accuracy  and  exposing  unclear  or 
incorrect  requirements  —  not  beauty  or 
completeness. 

The  final  good  practice  I  want  to  men¬ 
tion  applies  whether  or  not  you  are  using 
modeling:  I  always  tell  my  clients  to  con¬ 
duct  short  retrospectives  at  the  end  of 
each  requirements  iteration.  A  retrospective 
is  a  special  meeting  in  which  the  team 
explores  what  works,  what  does  not  work, 
what  can  be  learned  from  the  just  com¬ 
pleted  iteration,  and  what  ways  to  adapt 
their  processes  and  techniques  before 
starting  another  iteration  [10,  11]. 

Retrospectives  allow  for  early  learning  and 
correction  and  may  be  your  team’s  most 
powerful  tool  for  process  improvement. 

On  Your  Way 

Software  development  teams  enjoy  access 
to  a  world  of  tools  and  technologies,  but 
building  truly  successful  software  still 
depends  on  team  members  gaining  a  deep 
understanding  of  user  needs.  When  your 
team  is  developing  a  software  product, 
you  will  save  time,  money,  and  frustration 
by  using  appropriate  models  to  describe 
and  analyze  the  product’s  user  require¬ 
ments.  ♦ 

References 

1.  Reifer,  Donald  J.  “Profiles  of  Level  5 
CMMI  Organizations.”  CROSSTALK 
Jan.  2007. 

2.  Schwaber,  Carey.  “The  Root  of  the 
Problem:  Poor  Requirements.”  IT 
View  Research  Document.  Forrester 
Research,  2006 

3.  Dabney,  James  B.,  and  Gary  Barber. 
“Direct  Return  on  Investment  of 
Software  Independent  Verification  and 
Validation:  Methodology  and  Initial 
Case  Studies.”  Assurance  Technology 
Symposium,  June  2003  <http:// 
sarpresults.iw.nasa.gov/ViewResearch 
/24.jsp>. 

4.  Hooks,  Ivy  F.,  and  Kristina  A.  Farry. 
Customer-Centered  Products:  Creat¬ 
ing  Successful  Products  Through 
Smart  Requirements  Management. 
New  York:  Amacom,  2001. 

5.  Nelson,  Mike,  James  Clark,  and 
Martha  Ann  Spurlock.  “Curing  the 
Software  Requirements  and  Cost 


Estimating  Blues.”  The  Defense 
Acquisition  University  Program 
Manager  Magazine  Nov.-Dee.  1999. 

6.  Jones,  Capers.  Patterns  of  Software 
Systems  Failure  and  Success.  Boston, 
MA:  Thomson  Computer  Press,  1996. 

7.  Gottesdiener,  Ellen.  Software 

Requirements  Memory  Jogger: _ A 

Pocket  Guide  to  Help  Software  and 
Business  Teams  Develop  and  Manage 
Requirements.  Methuen,  MA: 
Goal/ QPC,  2005. 

8.  Institute  of  Electrical  &  Electronics 
Engineers  (IEEE).  “IEEE  Software 
Engineering  Body  of  Knowledge.” 
IEEE  Computer  Society,  2004 
<www.swebok.org>. 

9.  Standish  Group  International. 
“CHAOS  Chronicles.”  Standish 
Group  International,  2003. 

10.  Kerth,  Norman  L.  “Project  Retro¬ 
spectives:  A  Handbook  for  Team 
Reviews.”  New  York:  Dorset  House, 
2001. 

11.  Gottesdiener,  Ellen.  “Team  Retro¬ 
spectives  for  Better  Iteration  Assess¬ 
ment.”  The  Rational  Edge  Apr.  2003 
<http:/ /ebgconsulting.com/Pubs/ 
Articles/TeamRetrospectives-Gottes 
diener.pdf>. 

About  the  Author 

Ellen  Gottesdiener, 

principal  consultant,  EBG 
Consulting,  helps  get  the 
right  requirements  so 
projects  start  smart  and 
deliver  the  right  product 
at  the  right  time.  Her  book,  “Require¬ 
ments  by  Collaboration:  Workshops  for 
Defining  Needs”  describes  how  to  use 
multiple  models  to  elicit  requirements  in 
collaborative  workshops,  and  “The 
Software  Requirements  Memory  Jogger” 
describes  essentials  for  requirements 
development  and  management.  In  addi¬ 
tion  to  providing  training,  eLearning  and 
consulting  services,  she  speaks  at  and 
advises  for  industry  conferences,  writes 
articles,  and  serves  on  the  Expert  Review 
Board  of  the  International  Institute  of 
Business  Analysis  Business  Analysis 
Body  of  Knowledge. 

EBG  Consulting,  Inc. 

1424  Iron  wood  DR  West 
Carmel,  IN  46033 
Phone:  (317)  844-3747 
E-mail:  ellen@ebgconsulting.com 


Crosstalk # 

Th«  Jnurnil  of  Otlinia  loftwiri  f  n|i  n  i»rln| 

Get  Your  Free  Subscription 

Fill  out  and  send  us  this  form. 

517  SMXS/MXDEA 
6022  Fir  Ave 
Bldg  1238 

Hill  AFB,  UT  84056-5820 
Fax:  (801)  777-8069  DSN:  777-8069 
phone:  (801)  775-5555  DSN:  775-5555 

Or  request  online  at  www.stsc.hill.af.mil 

Name: _ 

Rank/Grade: _ 

Position/T  itle: _ 

Organization: _ 

Address: _ 


Base/City: _ 

State: _ Zip: _ 

Phone:  ( _ ) _ 

Fax:  ( _ ) _ 

E-mail: _ 

Check  Box(es)  To  Request  Back  Issues: 

Dec2006  □  Requirements  Eng. 
Jan2007  Q  Publisher’s  Choice 
Feb2007  □  CMMI 
Mar2007  □  Software  Security 
Apr2007  □  Agile  Development 
May2007  □  Software  Acquisition 
June2007  □  COTS  Integration 
July2007  □  Net-Centricity 
Aug2007  □  Stories  of  Change 
Sept2007  □  Service-Oriented  Arch. 
Oct2007  □  Systems  Engineering 
Nov2007  □  Working  as  a  Team 
Dec2007  Q  Software  Sustainment 
Jan2008  Q  Training  and  Education 
F eb2008  □  Small  Projects,  Big  Issues 

To  Request  Back  Issues  on  Topics  Not 
Listed  Above,  Please  Contact  <stsc. 

CUSTOMERSERVICE@HILL.AF.MIL>. 


March  2008 


www.stsc.hill.af.mil  I  7 


Tabular  Notations  for  State  Machine-Based  Specifications 
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Finite  state  machines  are  a  widely  used  concept  for  specifying  the  behavior  of  reactive  systems.  Numerous  graphical  notations 
based  on  finite  state  machines  have  been  developed  and  are  commonly  used  today,  such  as  state  transition  diagrams,  Harel 
statecharts,  and  Unified  Modeling  Uanguage  (UMU)  state  machine  diagrams.  While  not  as  widely  used,  tabular  notations 
for  state  machine-based  specifications  offer  complementary  advantages  to  diagrammatic  notations.  In  this  article,  we  describe 
five  approaches  using  tabular  notations  for  state  machine-based  specifications  and  evaluate  these  approaches  for  use  in  soft¬ 
ware  development. 


The  term  reactive  system  describes  a  sys¬ 
tem  that  needs  to  continuously  react 
to  inputs  coming  from  the  environment. 
Finite  state  machines  are  a  widely  used 
concept  for  specifying  the  behavior  of 
such  systems.  Since  finite  state  machines 
allow  the  rigorous  capture  of  functional 
aspects  of  system  behavior1,  they  offer 
several  advantages  over  informal  specifi¬ 
cations.  For  example,  they  provide  the 
ability  to  automatically  generate  code  or 
test  cases,  and  they  enable  formal  verifica¬ 
tion  and  validation  (V&V).  Generally,  a 
finite  state  machine  is  an  appropriate  rep¬ 
resentation  when  a  problem  or  solution 
has  the  following  characteristics: 

•  Finite  and  discrete  set  of  states  (e.g., 
on,  off,  and  standby). 

•  Discrete  and  manageable  set  of 
inputs. 

•  Change  of  state  is  only  performed  in 
response  to  an  input  (e.g.,  if  a  button 
is  pressed,  then  the  machine  transi¬ 
tions  from  state  off  to  state  on). 

State  machines2  are  used  for  specifying 
functional  properties  for  a  wide  variety  of 
systems,  such  as  control  systems  and  user 
interfaces.  For  example,  Siemens  uses 
state  machines  to  precisely  specify  the  cir¬ 
cuitry  in  mail  sorting  systems  and  the 
controls  in  car  radios.  They  are  also  the 
paradigm  of  choice  for  software  compiler 
design  and  programmatic  interpretation 
of  natural  language.  Numerous  graphical 
notations  for  state  machines  have  been 
developed  and  are  commonly  used  today, 
such  as  state  transition  diagrams,  Harel 
statecharts  [1],  and  UML  state  machine 
diagrams  [2].  Graphical  notations  are 
often  preferred  by  developers,  analysts, 
and  testers  over  textual  information,  since 
diagrams  allow  the  visualization  of  com¬ 
plex  relationships. 

Tabular  notations  for  state  machines  (com¬ 
monly  also  referred  to  as  state  tables  or  state 
transition  tables)  offer  complementary 
advantages  to  these  graphical  notations. 
For  example,  the  incompleteness  of  a 
specification,  i.e.,  the  actions  of  the  sys¬ 


tem  in  a  specific  state  in  response  to  a 
specific  event  that  are  not  addressed  by 
the  specification,  can  easily  be  identified 
as  empty  cells  in  the  table.  In  addition, 
tabular  notations  are  relatively  compact 
and  have  shown  to  scale  well  to  practical 
systems  [3].  Due  to  these  reasons,  tabular 
notations  for  state  machines  are  preferred 
in  some  domains  over  graphical  notations 
for  the  rigorous  specification  of  system 
behavior.  For  instance,  Siemens  Auto¬ 
motive  commonly  receives  system 
requirements  in  the  form  of  state  tables, 
captured  in  either  Excel  sheets  or  propri¬ 
etary  databases. 

While  a  tabular  representation  is  rela¬ 
tively  compact  and  the  completeness  of 
the  requirements  specification  can  easily 
be  determined,  it  has  been  shown  to 
cause  numerous  difficulties.  For  instance, 
the  requirements  specification  for  a  sys¬ 
tem  of  realistic  size  is  often  quite  large 
and  of  considerable  complexity,  consist¬ 
ing  of  numerous  large  tables.  As  a  result, 
precisely  understanding  the  required 
behavior  solely  through  visual  inspection 
is  difficult.  Moreover,  requirements  cap¬ 
tured  in  simple  Excel  sheets  are  difficult 
to  analyze  for  consistency  and  adherence 
to  critical  properties. 

This  article  presents  and  evaluates 
several  state  machine-based  tabular  nota¬ 
tions  that  can  address  some  of  the  afore¬ 
mentioned  problems.  For  instance,  some 
notations  enhance  the  under standability 
of  the  specification  by  offering  a  comple¬ 
mentary  graphical  representation.  In  addi¬ 
tion,  hierarchical  composition  is  used  by 
several  notations  to  keep  the  specification 
tractable  and  some  provide  tool  support 
for  V&V.  The  remainder  of  this  article  is 
organized  as  follows:  the  Background  sec¬ 
tion  provides  an  overview  of  finite  state 
machines  and  Harel  statecharts.  The 
Tabular  Notations  for  State  Machines  sec¬ 
tion  describes  five  approaches  using  tabu¬ 
lar  notations  for  state  machine-based 
specifications.  We  conclude  by  evaluating 
these  notations  for  use  in  software  devel¬ 


opment  with  respect  to  several  factors. 

Background 

This  section  introduces  finite  state 
machines,  including  a  common  graphical 
and  tabular  notation,  and  briefly  describes 
the  advanced  features  of  Harel  state- 
charts. 

Finite  State  Machine 

The  term  finite  state  machine  describes  a 
class  of  computational  models  that  con¬ 
sist  of  a  finite  set  of  states,  a  start  state, 
a  set  of  inputs  (events),  and  a  transition 
function  that  determines  the  next  state  of 
the  finite  state  machine  based  on  the  cur¬ 
rent  state  and  input  [4].  The  finite  state 
machine  starts  computation  in  the  start 
state;  transitions  between  states  are  per¬ 
formed  based  on  the  transition  function. 
Numerous  variants  of  this  basic  type  of 
state  machine  exist.  For  example,  Moore 
machines  extend  finite  state  machines 
with  outputs  (actions)  associated  with 
states,  while  Mealy  machines  associate 
outputs  with  transitions  [5].  For  the 
remainder  of  this  article,  we  use  Mealy 
machines  as  the  computational  model. 
Finite  state  machines  may  be  determinis¬ 
tic  or  non-deterministic.  In  deterministic 
finite  state  machines  for  a  given  input, 
one  transition  can  be  taken  from  the  cur¬ 
rent  state,  at  most.  In  non-deterministic 
finite  state  machines,  however,  one  input 
may  enable  several  transitions  of  which 
one  is  then  taken. 

A  common  way  of  representing  finite 
state  machines  is  the  use  of  state  transition 
diagrams  (commonly  also  referred  to  as 
state  diagrams).  State  transition  diagrams 
are  directed  graphs  in  which  states  are 
depicted  as  nodes  and  transitions  are  rep¬ 
resented  by  directed  edges.  Transitions 
are  commonly  labeled  with  the  triggering 
events  and  actions,  using  the  following 
general  syntax:  trigger/ action (s).  Figure  1 
contains  a  sample  state  transition  dia¬ 
gram  showing  the  simple  behavior  of  a 
door:  The  door  can  be  opened  or  closed. 
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push_in/ 
sound  alarm 


push_in/ 
sound  alarm 


\  \ 


Broken 


Action 


Figure  1 :  Sample  State  Transition  Diagram 


If  the  door  is  closed,  then  it  can  be 
locked  or  unlocked.  The  door  can  only 
be  opened  when  it  is  unlocked.  If  the 
door  is  closed  (irrespective  of  being 
locked  or  unlocked),  then  it  can  be 
pushed  in.  Because  of  this  event,  an 
alarm  will  sound  and  the  door  will  then 
be  permanently  in  the  state  Broken. 

In  addition  to  the  graphical  represen¬ 
tation,  finite  state  machines  may  be  spec¬ 
ified  using  state  transition  tables.  A  state 
transition  table  denotes  the  action  per¬ 
formed  by  the  automaton  and  the  next 
state  based  on  the  current  state  (row)  and 
event  that  occurred  (column).  A  dash 
denotes  that  no  such  transition  exists.  A 
state  transition  table  representing  the 
automaton  specified  in  Figure  1  can  be 
seen  in  Table  1.  Using  this  tabular  nota¬ 
tion,  completeness  of  the  specification 
can  be  readily  established.  Since  a  cell 
needs  to  be  labeled  explicitly  with  a  dash 
if  no  such  transition  exists,  a  cell  that 
does  not  contain  a  destination  state  or  a 
dash  renders  the  specification  incom¬ 
plete.  Using  a  graphical  notation,  deter¬ 
mining  the  completeness  of  the  specifi¬ 
cation  is  more  difficult,  since  a  missing 
arrow  in  a  diagram  could  potentially  be 
the  result  of  an  omission,  but  could  also 
mean  that  no  such  transition  exists. 

Harel  Statecharts 

While  finite  state  machines  have  shown  to 
be  useful  for  modeling  reactive  systems, 
their  representation  as  state  transition  dia¬ 
grams  does  not  scale  well  to  large-scale 
systems  and  may  become  unstructured, ,  unre¬ 
alistic ,  and  chaotic.  To  address  this  problem, 
David  Harel  developed  statecharts  that 
extend  state  transition  diagrams  with  the 
following  concepts  [1]: 

1.  Depth.  Commonly  also  referred  to  as 
XOR  (eXclusive  OR)  decomposition  or 
state  nesting.  Using  state  nesting,  a  state 
may  be  a  composite  state  that  con¬ 
tains  exactly  one  region  serving  as  a 
container  for  sub  states.  To  be  in  the 
composite  state,  the  system  must  be 
in  exactly  one  of  its  sub  states  (which 
itself  may  be  composite  states  again). 

2.  Orthogonality.  Also  known  as  AND 
decomposition.  Using  FIND  decompo¬ 
sition ,  a  state  may  be  a  composite  state 
comprising  two  or  more  orthogonal 
regions  executing  independently  and 
concurrently.  Therefore,  to  be  in  the 
composite  state,  the  system  must  be 
in  a  state  of  all  of  its  orthogonal 
regions  at  the  same  time.  Each 
orthogonal  region  may  itself  contain 
additional  composite  states. 

3.  Broadcast  communication.  Since 
orthogonal  regions  are  independent 


and  execute  concurrently,  the  compu¬ 
tational  model  of  statecharts  uses 
broadcast  communication.  As  a 
result,  each  orthogonal  region 
receives  occurring  events  and  may 
take  transitions  that  had  become 
enabled. 

In  addition  to  these  basic  extensions, 
Harel  statecharts  provide  additional  con¬ 
structs  such  as  entry  and  exit  actions  for 
states,  conditionals,  and  history  states 
(see  [1]  for  more  details).  The  UML  nota¬ 
tion  for  state  machines  is  based  on  Harel 
statecharts  and  uses  a  number  of  these 
extensions.  (For  a  detailed  comparison  of 
the  syntax  and  semantics  of  UML  state 
machine  diagrams  and  Harel  statecharts, 
please  refer  to  [6].)  Figure  2  (see  page  20) 
shows  how  statecharts  provide  more 
structure  and  reduce  the  perceived  com¬ 


plexity  of  the  diagrammatic  representa¬ 
tion  of  the  door  example  in  comparison 
to  the  state  transition  diagram  in  Figure 
1.  For  instance,  after  the  introduction  of 
a  composite  state  Closed  in  Figure  2, 
describing  the  behavior  of  the  door 
when  it  is  pushed  in  requires  only  one 
transition,  which  makes  the  diagram 
appear  cleaner  and  less  cluttered.  In  gen¬ 
eral,  the  extensions  provided  by  Harel 
statecharts  and  UML  state  machine  dia¬ 
grams  have  shown  to  be  an  effective 
means  to  reduce  the  perceived  complexi¬ 
ty  of  state  machine  representations  for 
reactive  systems.  For  example,  the 
authors  in  [7]  performed  some  studies 
with  university  students  and  concluded 
that  the  use  of  composite  states  in  UML 
state  machine  diagrams  improves  under- 
standability. 


Table  1 :  State  Transition  Table  Corresponding  to  Figure  1 


^^^Event 

State^^^ 

open_door 

close_door 

lock 

unlock 
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Opened 

- 

/Closed, 
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- 

- 

- 
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Unlocked 

/Opened 

- 

/Closed, 

Locked 

- 

sound_alarm/ 

Broken 

Closed, 

Locked 

- 

- 

- 

/Closed, 

Unlocked 

sound_alarm/ 

Broken 

Broken 

- 

- 

- 

- 

- 
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Figure  2:  Sample  Statechart 


Tabular  Notations  for  State 
Machines 

This  section  describes  five  approaches  that 
use  tabular  notations  for  state  machine- 
based  models,  namely  Virtual  Finite  State 
Machines  (VFSM)  [8],  Software  through 
Pictures  (StP)  [9],  Parnas  Tables  [10], 
Software  Cost  Reduction  (SCR)  [3],  and 


the  Requirements  State  Machine  Language 
(RSML)  [11]. 

VFSMs 

The  VFSM  is  a  concept  for  the  specifica¬ 
tion  of  control  systems  in  a  virtual  envi¬ 
ronment.  The  environment  is  termed  vir¬ 
tual  since  events  and  actions  of  the  envi¬ 
ronment  are  represented  by  abstract 


names  for  inputs  and  outputs  in  the  state 
machine  [8].  The  behavior  of  the  system 
may  be  specified  as  a  state  table  that  shows 
actions  and  transitions  performed  in  a  cer¬ 
tain  state  based  on  specific  conditions. 
Table  2  shows  a  sample  state  table  for 
Statei.  Upon  entering  the  state.  Outputs  is 
always  produced  and  upon  exiting  the 
state,  Output2  is  always  produced.  If 
Conditiom  is  satisfied,  then  Output3  is  pro¬ 
duced  without  causing  a  state  change 
(internal  transition).  However,  if  Conditiom 
is  satisfied,  then  Output4  is  produced  and 
the  state  machine  transitions  to  State2 
(external  transition). 

While  VFSMs  support  entry  and  exit 
actions,  they  do  not  support  state  nesting 
or  orthogonality.  However,  different  sets 
of  concurrent  high-level  and  low-level 
finite  state  machines  can  be  created  and 
connected  to  achieve  structuring  through 
hierarchical  decomposition  [12]. 

The  application  of  VFSMs  is  facilitat¬ 
ed  by  StateWORKS  Studio,  a  tool  suite  for 
creating  specifications  using  VFSMs  [13]. 
The  tool  suite  offers  an  editor  that  com¬ 
bines  and  synchronizes  diagrammatic  and 
tabular  views  of  VFSMs.  In  addition,  a 
simulator  and  an  executor  are  provided 
that  can  be  used  to  validate  and  execute 
VFSM  specifications. 

StP 

StP  Structured  Environment  (SE)  is  a  tool- 
supported  approach  for  specifying  a  system 
using  diagrammatic  notation  complement¬ 
ed  with  tabular  notation  [9].  The  behavior 
of  a  system  is  specified  in  terms  of  control 
flow  diagrams  and  state  transition  dia¬ 
grams.  Complementary  to  state  transition 
diagrams,  two  tabular  notations  are  provid¬ 
ed:  state  event  matrix  and  state  transition  table. 

A  state  event  matrix  shows  all  transi¬ 
tions  of  the  state  machine  in  a  grid  of 
source  states  and  triggering  events.  Similar 
to  the  state  transition  table  shown  in  Table 
1 ,  a  transition  is  entered  into  the  cell  at  the 
intersection  of  its  source  state  (row)  and 
its  triggering  event  (column).  The  cell  con¬ 
tains  the  list  of  actions  to  perform  and  the 
target  state  of  the  transition.  Table  3 
shows  an  example  state  event  matrix,  in 
which  the  state  machine  transitions  from 
Statei  to  State2  upon  occurrence  of  Eventi , 
producing  Action^  and  it  transitions  back 
to  Statei  upon  occurrence  of  Event2 ,  pro¬ 
ducing  Actiom.  If  Id  vent 3  occurs  in  States 
then  the  state  machine  performs  Actions 
but  remains  in  the  current  state. 

A  state  transition  table  shows  all  tran¬ 
sitions  of  a  state  machine  in  a  list  (refer  to 
Table  4).  The  tabular  layout  provides  a 
column  for  the  source  state,  the  triggering 
event,  the  action,  and  the  target  state. 


Table  2:  VFSM  State  Table 


Table  3:  StP  SE  State  Event  Matrix 


State 

Event 

Eventi 

Event2 

Events 

Statei 

Action  i 

Actions 

State2 

Statei 

State2 

Action2 

Statei 
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The  tabular  notations  provided  by  StP 
SE  are  compact  and  readable.  However, 
diagrams  and  tables  of  StP  SE  provide 
neither  state  nesting  nor  orthogonal 
regions.  Similar  to  VFSMs,  structuring  is 
possible  using  hierarchical  decomposition. 
In  order  to  facilitate  the  implementation 
phase,  the  StP  SE  tool  suite  provides  code 
generation  and  reverse  engineering  capa¬ 
bilities  for  the  C  programming  language. 

Pa  mas  Tables 

Parnas  and  Madey  developed  the  four- 
variable  model  as  an  underlying  state 
machine  model  to  formally  specify  system 
requirements  [14].  The  name  of  the  model 
arises  from  the  fact  that  a  specification 
contains  four  distinct  sets  of  variables: 

•  Variables  monitored  by  the  system 
(MON). 

•  Variables  controlled  by  the  system 
(CON). 

•  Variables  that  the  input  devices  of  the 
system  read  from  (INPUT). 

•  Variables  that  the  output  devices  of 
the  system  write  to  (OUTPUT). 

The  relations  between  the  variable  sets  of 
the  four-variable  model  are  illustrated  in 
Figure  3. 

Specifically,  the  variables  are  linked  by 
the  following  five  relations: 

•  Natural  constraints  on  the  monitored 
and  controlled  variables  (NAT). 

•  Expected  change  of  controlled  vari¬ 
ables  in  response  to  changes  in  moni¬ 
tored  variables,  i.e.,  the  actual  system 
requirements  (REQ). 

•  Relation  of  monitored  variables  to 
input  variables  (IN). 

•  Relation  of  controlled  variables  to  out¬ 
put  variables  (OUT). 

•  Relation  between  input  and  output 
variables,  realized  by  software  (SOFT). 
A  possible  notation  for  expressing 

these  relations  are  Parnas  Tables  [10]. 
Parnas  Tables  are  a  collection  of  10  table 
types  for  capturing  functional  and  rela¬ 
tional  expressions,  each  having  a  distinct 
syntax  and  semantics.  A  developer  should 
choose  the  table  format  that  produces  a 
simple,  compact  representation  for 
expressing  the  relation  at  hand.  For  each 
table  type,  rules  exist  for  identifying 
incompleteness  and  inconsistency. 

Table  5  (see  page  22)  contains  a  sam¬ 
ple  Parnas  Table  of  type  decision  table.  A 
decision  table  can  represent  a  function  or 
relation  where  the  domain  is  an  ordered 
set  of  potentially  distinct  types.  One 
dimension  of  the  table  itemizes  the  ele¬ 
ments  of  the  domain.  Table  5  shows  the 
syntax  of  a  decision  table  representing  the 
relation  between  two  variables,  A  and  B , 
and  a  decision  that  is  made  based  on  the 


Current  State 

Event 

Action 

Next  State 

State  i 

Evenfi 

Actio  ni 

State2 

State  i 

Event3 

Action3 

State  i 

State2 

Event2 

Actio  ri2 

State  i 

Table  4:  StP  SE  State  Transition  Table 


values  of  these  variables.  For  instance, 
Table  5  states  that  if  A  —  A2  and  B  -  B2 
then  make  Decision. 

Parnas  Tables  do  not  support  nesting 
or  orthogonality,  but  allow  the  developer 
to  reference  a  function  that  is  defined  in  a 
different  table.  Since  Parnas  Tables  have 
completely  formal  semantics,  tool  support 
can  be  developed  to  check  the  tables  auto¬ 
matically.  However,  to  the  best  of  our 
knowledge,  such  tool  support  is  not  cur¬ 
rently  available. 

SCR 

SCR  is  a  set  of  formal  methods  for  the 
design  of  software  systems  [3].  Similar  to 
Parnas  tables,  SCR  also  uses  the  four-vari¬ 
able  model  as  its  underlying  abstraction,  and 
the  relationships  between  monitored  and 
controlled  variables  are  captured  in  tables 
[10,  14]. 

In  order  to  capture  the  relations  con¬ 
cisely,  SCR  defines  modes.  A  mode 
describes  a  set  of  system  states  in  which 
the  system  exhibits  equivalent  behavior  in 
response  to  events  and  conditions.  Mode 
classes  then  describe  the  relationships 
between  these  modes  and  are  modeled  in 
terms  of  mode  transition  tables.  In  order 
to  model  complex  systems  with  indepen¬ 
dent  components,  several  mode  classes 
may  be  constructed  to  capture  concurren¬ 
cy.  The  occurrence  of  an  event  is  denoted 
by  a  value  change  of  a  condition.  @T  is 
used  to  specify  that  a  condition  becomes 
true,  while  @F  specifies  that  a  condition 
becomes  false. 

SCR  uses  three  different  types  of 
tables  to  specify  a  system:  condition  tables , 
event  tables,  and  mode  transition  tables. 

A  condition  table  defines  the  value  of 
a  variable  depending  on  the  mode  and  a 
condition.  For  example,  in  Table  6,  the 
variable  van  is  assigned  the  value  greater ; 
equal,  or  less  in  the  modes  Mi  and  M2  of 
mode  class  MCi ,  depending  on  the  values 
of  variables  van  and  van. 

An  event  table  defines  the  value  of  a 
variable  as  a  function  of  the  mode  and  a 
(possibly  conditioned)  event.  For  example, 
Table  7  (see  page  22)  assigns  variable  van  a 
true  or  false  value  in  the  modes  Mi  and  M2 
of  mode  class  MCi  based  on  a  change  in 
value  of  the  variable  van. 

Finally,  the  mode  transition  table 


defines  how  the  mode  of  a  mode  class 
changes  in  response  to  events.  A  sample 
mode  transition  table  for  the  mode  class 
MCi  is  given  in  Table  8.  Specifically,  the 
system  changes  from  mode  Mi  to  mode  M2 
upon  variable  van  becoming  true,  and 
switches  back  to  mode  Mi  if  the  variable 
becomes  false.  Commonly,  a  mode  transi¬ 
tion  table  contains  only  events  that  change 
the  mode;  events  that  do  not  cause  mode 
changes  are  omitted  to  increase  readability. 

The  SCR  notation  is  rigorous  and  com¬ 
pact,  but  purely  tabular.  Nesting  and 
orthogonality  are  not  supported  by  the 
notation,  but  hierarchical  decomposition 
can  be  used  to  structure  complex  systems. 
Tools  to  support  various  V&V  approaches 
have  been  developed  [3].  Once  the  system 
model  is  complete,  the  model  can  be 
checked  for  different  types  of  errors,  such 
as  incompleteness  or  ambiguities.  In  addi¬ 
tion,  a  simulator  can  be  used  to  run  sce¬ 
narios  and  inspect  whether  the  results  are 
as  expected. 


RSML 

The  RSML  was  originally  developed  to 
write  requirements  specifications  for 
process-control  systems  such  as  a  collision 
avoidance  system  for  a  commercial  airlin¬ 
er  [11].  RSML  combines  a  graphical  nota¬ 
tion  based  on  Harel  statecharts  with  a  tab¬ 
ular  notation  for  specifying  transition  con¬ 
ditions.  As  such,  RSML  retains  most  of 
the  advanced  features  of  statecharts,  such 
as  depth  and  orthogonality,  while  using 
tables  to  facilitate  the  readability  of  condi¬ 
tions  associated  with  transitions. 

RSML  specifications  generally  consist 
of  state  diagrams  with  unlabeled  transi¬ 
tions.  Transitions  are  not  labeled  in  order 
to  increase  the  readability  of  a  state  dia¬ 
gram  when  enabling  conditions  of  transi¬ 
tions  are  complex.  Instead  of  using  labels. 


Figure  3:  Tour-Variable  Model  [14] 
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Decisioni 

Decision 

Decisions 

A 

Ai 

a2 

a3 

B 

Bi 

b2 

b3 

Table  5:  Parnas  Decision  Table 


Mode  Class 

MCi 

Conditions 

Mi,  M2 

van  <  var2 

van  =  var2 

van  >  var2 

var3 

greater 

equal 

less 

Table  6:  SCR  Condition  Table  for  Variable  Van 


Mode  Class 

MCi 

Events 

Mi,  M2 

@T(var3  =  equal) 

@T(var3=  greater)  OR 
@T(var3=  less) 

van 

true 

false 

Table  7:  SCR  Trent  Table  for  Variable  Van 


Old  Mode 

Event 

New  Mode 

Mi 

@T(var4) 

m2 

m2 

@F(var4) 

Mi 

Table  8:  SCR  Mode  Transition  Table  for  Mode  Class  MCi 


properties  of  transitions  are  defined  sepa¬ 
rately  from  the  diagrams  in  transition  def¬ 
initions.  A  transition  definition  contains 
the  source  and  destination  of  the  transi¬ 
tion,  the  state  machine  where  the  transi¬ 
tion  is  located,  the  triggering  event,  the 
guarding  condition,  and  the  output  action. 
The  guarding  condition  of  a  transition  is 
defined  in  terms  of  AND/OR  tables.  A 
sample  AND/OR  table  can  be  seen  in 
Table  9,  which  describes  that  the  associat¬ 
ed  transition  is  enabled  (after  the  trigger¬ 
ing  event  has  occurred)  when  Expressiom  is 
true  AND  Expression 2  is  false  at  the  same 
time,  OR  Expression  is  found  to  be  true. 
The  period  denotes  that  the  truth  value  of 
the  expression  is  irrelevant  for  the  current 
evaluation. 

The  final  RSML  specification  can 
then  be  checked  for  consistency  and 
completeness.  In  addition,  techniques 

Table  9:  RSML  AND/  OR  Table 

OR 


Expressioni 

T 

Expression 

F 

Expressions 

T 

have  been  developed  that  allow  the  analy¬ 
sis  of  RSML  specifications  using  theorem 
proving  and  model  checking  techniques 
[15].  As  such,  the  correctness  of  an 
RSML  specification  can  be  rigorously 
established.  Similar  to  SCR,  tools  sup¬ 
porting  the  simulation  of  RSML  specifi¬ 
cations  also  exist. 

Conclusions 

Due  to  advanced  syntactical  and  semanti¬ 
cal  features,  Harel  statecharts  and  UML 
state  machine  diagrams  are  better  suited 
than  the  basic  state  transition  diagram 
notation  to  handle  complex  systems. 
Similarly,  the  five  presented  approaches 
use  advanced  features  that  make  them 
better  suited  for  complex  systems  than 
basic  state  transition  tables.  Analysts  or 
developers  that  need  to  determine  which 
approach  to  use  in  their  development 
processes  should  consider  several  factors. 
If  the  main  goal  is  to  facilitate  the  imple¬ 
mentation  phase  and  reduce  coding 
efforts,  then  the  VFSMs  and  StP 
approaches  seem  preferable,  since  they 
offer  commercially  available  tool  support 
that  allows  executing  or  generating  code 
from  the  specifications. 

However,  if  the  focus  is  the  formal 


analysis  of  the  system  specification  for 
various  completeness  and  correctness 
properties,  Parnas  Tables,  SCR,  and 
RSML  are  better  suited.  Since  Parnas 
Tables  do  not  offer  tool  support  and 
require  the  user  to  understand  the  syntax 
and  semantics  of  each  possible  table  type, 
they  can  only  be  recommended  to  devel¬ 
opers  with  a  solid  understanding  of  for¬ 
mal  methods  that  do  not  need  automated 
support  for  formal  analysis.  In  contrast  to 
Parnas  Tables,  SCR  and  RSML  offer 
mature  tool  support  for  V&V.  When 
deciding  between  SCR  and  RSML,  an 
important  factor  may  be  the  availability  of 
a  graphical  representation.  While  SCR  is 
purely  tabular,  RSML  uses  the  tabular  rep¬ 
resentation  only  for  capturing  the  guard¬ 
ing  conditions  of  transitions,  while  states 
and  unlabeled  transitions  are  captured  in 
terms  of  diagrams.  We  believe  that  such  a 
combination  of  diagrammatic  and  tabular 
views  combines  the  specific  advantages 
each  of  these  views  offer.  In  addition  to 
combining  graphical  and  tabular  views, 
RSML  also  supports  the  concepts  of  nest¬ 
ing  and  orthogonality  of  Harel  statecharts. 
These  concepts  have  shown  to  be  effec¬ 
tive  means  to  reduce  the  perceived  com¬ 
plexity  of  models.  Dutertre  and  Stavridou 
have  examined  the  use  of  SCR  and  RSML 
for  an  avionic  storage  management  system 
specification  and  concluded  that  RSML 
specifications  are  commonly  easier  to 
understand  than  SCR  specifications  due  to 
these  structuring  features  [16]. 

In  conclusion,  we  believe  that  while 
tabular  notations  for  state  machines  are 
not  a  silver  bullet  solution,  they  may  greatly 
facilitate  the  specification  and  analysis  of 
systems  in  specific  domains.  Tabular  nota¬ 
tions  seem  to  be  explicitly  useful  for  sys¬ 
tems  with  a  large  number  of  transitions 
between  states  or  rather  complex  enabling 
conditions  of  transitions.  In  order  to 
retain  the  advantage  of  having  a  graphical 
view,  the  presented  VFSM,  StP  SE,  and 
RSML  approaches  use  tables  and  dia¬ 
grams.  As  such,  they  attempt  to  combine 
the  complementary  advantages  of  dia¬ 
grammatic  and  tabular  notations.  In  addi¬ 
tion,  if  the  system  under  design  is  rather 
complex  (i.e.,  having  a  large  number  of 
states  and  transitions),  notations  support¬ 
ing  nesting  and  orthogonality  may  provide 
a  significant  reduction  in  specification 
complexity.  The  mature  V&V  tool  sup¬ 
port  offered  by  some  of  the  presented 
approaches  also  offers  significant  advan¬ 
tages  over  specifications  using  Excel 
tables  or  proprietary  databases,  where 
often  the  only  available  means  of  analysis 
is  visual  inspection.^ 
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Notes 

1.  Non- functional  aspects,  such  as  per¬ 
formance  and  reliability,  are  usually 
captured  by  different  means. 

2.  For  the  remainder  of  this  article,  we 
assume  that  the  system  being  specified 
has  a  finite  set  of  states  and  we  use  the 
terms  finite  state  machine  and  state 
machine  interchangeably 
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Addressing  the  Challenges  ofTactical  Information 
Management  in  Net-Centric  Systems  With  DDS 

Dr.  Douglas  C.  Schmidt,  Dr.  Angelo  Corsaro,  and  Hans  van’t  Hag 

PrismTech  Corporation 

Kecent  trends  in  net-centric  systems  motivate  the  development  of  tactical  information  management  capabilities  that  ensure  the 
right  information  is  delivered  to  the  right  place  at  the  right  time  to  satisfy  quality  of  service  (QoS)  requirements  in  heteroge¬ 
neous  environments.  This  article  presents  an  architectural  overview  of  the  Object  Management  Group’s  (OMG)  Data 
Distribution  Service  (DDS),  which  is  a  standards-based  QoS -enabled  data-centric  middleware  p la,  form  that  enables  applica¬ 
tions  to  communicate  by  publishing  information  they  have  and  subscribing  to  information  they  need  in  a  timely  manner.  DDS 
is  an  important  distributed  software  technology  for  mission-critical  Department  of  Defense  (DoD)  net-centric  systems  because 
it  supports  the  following:  (1)  location  independence,  via  anonymous  publish / subscribe  (pub /  sub)  protocols  that  enable  commu¬ 
nication  between  collocated  or  remote  publishers  and  subscribers,  (2)  scalability,  by  supporting  large  numbers  of  topics,  data 
readers,  and  data  writers  and  plaform  portability,  and  (3 )  interoperability,  via  standard  inte  faces  and  transport  protocols. 


Tactical  information  management  sys¬ 
tems  increasingly  run  in  net-centric 
environments  characterized  by  thousands 
of  platforms,  sensors,  decision  nodes,  and 
computers  connected  together  to 
exchange  information,  support  sense¬ 
making,  enable  collaborative  decision 
making,  and  effect  changes  in  the  physical 
environment.  For  example,  the  Global 
Information  Grid  (GIG)  is  an  ambitious 
net-centric  environment  being  designed  to 
ensure  that  different  services  and  coalition 
partners,  as  well  as  individuals  participat¬ 
ing  to  specific  missions,  can  collaborate 
effectively  and  deliver  appropriate  fire¬ 
power,  information,  or  other  essential 
assets  to  warfighters  in  a  timely,  depend¬ 
able,  and  secure  manner  [1].  Achieving 
this  vision  requires  the  following  capabili¬ 
ties  from  the  distributed  middleware  soft¬ 
ware: 

•  Shared  operational  picture.  A  key 

requirement  for  mission-critical  net- 
centric  systems  is  the  ability  to  share 
an  operational  picture  with  planners, 
warfighters,  and  operators  in  real-time. 
•  Ensure  the  right  data  gets  to  the 
right  place  at  the  right  time  by  satis¬ 
fying  end-to-end  QoS  requirements, 
such  as  latency,  jitter,  throughput, 
dependability,  and  scalability. 

•  Interoperability  and  portability  in 
heterogeneous  environments.  Since 
net-centric  systems  are  faced  with 
unprecedented  challenges  in  terms  of 
platform  and  network  heterogeneity, 
they  are  necessary. 

•  Support  for  dynamic  coalitions.  In 

many  net-centric  tactical  information 
management  systems,  dynamically 
formed  coalition  of  nodes  will  need  to 
share  a  common  operational  picture 
and  exchange  data  seamlessly. 

Prior  middleware  technologies  (such  as 


the  Common  Object  Request  Broker 
Architecture  [CORBA]  Event  Service  and 
Notification  Service,  the  Java  Message 
Service  QMS],  and  various  other  propri¬ 
etary  middleware  products)  have  histori¬ 
cally  lacked  key  architectural  and  QoS 
capabilities,  such  as  dependability,  surviv¬ 
ability,  scalability,  determinism,  security, 
and  confidentiality  needed  by  net-centric 
systems  for  tactical  information  manage¬ 
ment.  To  address  these  limitations  -  and 
to  better  support  tactical  information 
management  in  net-centric  systems  like 
the  GIG  —  the  OMG  has  adopted  the 
DDS  specification,  which  is  a  standard  for 
QoS-enabled  data-centric  pub/ sub  com¬ 
munication  aimed  at  net-centric  tactical 
information  management  systems  [2]. 
DDS  is  used  in  a  wide  range  of  military 
and  commercial  systems  including  naval 
combat  management  systems,  commercial 
air  traffic  control,  transportation  manage¬ 
ment,  automated  stock  trading  systems, 
and  semiconductor  fabrication  devices. 

The  remainder  of  this  article  presents 
an  overview  of  DDS  that  is  geared  to 
software  architects.  We  also  discuss  the 
DDS  QoS  policies  that  are  the  most  rele¬ 
vant  for  net-centric  tactical  information 
management  systems.  Finally,  we  explain 
how  DDS  has  been  applied  in  practice  to 
address  key  challenges  of  developing  and 
operating  distributed  software  in  current 
and  planned  net-centric  tactical  informa¬ 
tion  management  systems. 

Overview  of  DDS 

DDS  provides  the  following  capabilities 
for  net- centric  tactical  information  sys¬ 
tems: 

•  Universal  access  to  information 

from  a  wide  variety  of  sources  that  run 

over  potentially  heterogeneous  hard¬ 
ware/software  platforms  and  net¬ 


works. 

•  An  orchestrated  information  bus 

that  aggregates,  filters,  and  prioritizes 
the  delivery  of  this  information  to 
work  effectively  under  the  restrictions 
of  transient  and  enduring  resource 
constraints. 

•  Continuous  adaptation  to  changes 

in  the  operating  environment,  such  as 
dynamic  network  topologies,  publisher 
and  subscriber  membership  changes, 
and  intermittent  connectivity. 

•  Standard  QoS  policies  and  mecha¬ 
nisms  that  enable  applications  and 
administrators  to  customize  the  way 
information  is  delivered,  received,  and 
processed  in  the  appropriate  form  and 
level  of  detail  to  users  at  multiple  lev¬ 
els  in  net-centric  systems. 

This  section  describes  the  key  capabil¬ 
ities  and  entities  in  DDS  and  shows  how 
its  QoS  policies  can  be  used  to  specify  and 
enforce  performance-related  requirements 
of  net-centric  tactical  information  man¬ 
agement  systems.  Figure  1  shows  the  vari¬ 
ous  profiles  and  layers  in  the  DDS  stan¬ 
dard.  The  lower  layer  defines  a  Data- 
Centric  Publish  Subscribe  (DCPS)  plat¬ 
form,  whose  goal  is  to  provide  efficient, 
scalable,  predictable,  and  resource-aware 
data  distribution.  The  higher  layer  is  the 
Data  Local  Reconstruction  Layer  (DLRL), 
which  is  an  optional  interface  that  pro¬ 
vides  an  object-oriented  facade  atop  the 
DCPS.  The  DLRL  can  be  used  to  map 
topics  onto  object  fields  and  defines  navi¬ 
gable  associations  between  objects. 

A  separate  specification,  called  the 
Real-Time  Publish/Subscribe  (RTPS) 
DDS  interoperability  wire  protocol, 
defines  the  standard  network  protocol 
used  to  exchange  data  between  publishers 
and  subscribers  that  use  different  imple¬ 
mentations  of  DDS  [3].  The  remainder  of 
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Data  Centric  Publish  Subscribe  (DCPS) 


Figure  1 :  Profiles  and  Payers  in  the  DDS  Standard 


this  section  describes  the  conceptual 
model  of  DDS  and  explains  the  QoS  poli¬ 
cies  that  are  most  relevant  for  net-centric 
tactical  information  management  systems. 

DDS  Conceptual  Model 

Domains  and  Partitions 

DDS  applications  send  and  receive  data 
within  a  domain.  Domains  can  be  divided 
into  partitions  that  allow  the  separation 
and  protection  of  different  data  flows. 
Although  DDS  entities  can  belong  to  dif¬ 
ferent  domains,  only  participants  within 
the  same  domain  can  communicate,  which 
helps  isolate  and  optimize  communication 
within  communities  that  share  common 
interests.  For  example,  each  communica¬ 
tion  layer  within  the  GIG  could  be  associ¬ 
ated  with  a  DDS  domain  and  further  sub¬ 
divided  into  partitions.  This  approach  iso¬ 
lates  domain  participants  across  layers, 
which  enables  effective  use  of  resources 
and  helps  enforce  security  and  confiden¬ 
tiality  policies. 

Global  Data  Space 

DDS  provides  a  strongly  typed  global  data 
space  within  each  domain  in  which  appli¬ 
cations  produce  and  consume  the  dynam¬ 
ically  changing  portions  of  a  shared  infor¬ 
mation  model,  as  shown  in  Figure  2.  DDS’ 
information  model  capabilities  are  similar 
to  those  of  relational  databases,  except 
that  DDS’  global  data  space  is  completely 
distributed,  QoS-aware,  and  allows  anony¬ 
mous  and  asynchronous  sharing  of  a 
common  information  model.  The  DDS 
information  model  is  the  only  knowledge 
publishers  and  subscribers  need  to  com¬ 
municate,  i.e.,  they  need  not  be  aware  of 
each  other  nor  be  concerned  with  low- 
level  network  programming  details,  such 
as  Internet  protocol  addresses,  port  num¬ 
bers,  remote  object  references,  or  service 
names.  By  allowing  data  to  flow  where  and 
when  needed,  DDS’s  global  data  space 
enables  the  sharing  of  tactical  information 
and  situational  awareness  information 
needed  to  implement  net-centric  tactical 
information  management  systems. 

Topic 

A  DDS  topic  is  an  association  between  a 
data  type,  a  set  of  QoS,  and  a  unique 
name,  as  shown  in  Figure  3  (see  page  26). 
A  topic  is  also  the  unit  of  information 
contained  in  DDS’  global  data  space  and 
is  used  by  applications  to  define  their 
information  model  and  associate  QoS 
policies  with  it.  DDS  applications  in  net- 
centric  systems  define  their  information 
model  by  identifying  topics  that  are  rele¬ 
vant  for  solving  their  requirements  and 
organizing  them  into  either  relational  or 
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object-oriented  models.  DDS  thus  allows 
the  expression  of  the  system  information 
model  as  either  a  1)  topic  relational  model, 
which  can  be  thought  of  as  an  extension 
of  the  familiar  entity  relationship  diagrams 
used  in  data  bases,  decorated  with  QoS,  or 
2)  an  object-oriented  model,  which  can 
also  be  synthesized  as  an  object-oriented 
view  of  the  relational  model. 

The  DCPS  layer  provides  support  for 
relational  modeling,  while  the  DLRL 
extends  the  DCPS  with  an  object-oriented 
facade,  so  that  applications  can  either 
completely  ignore  the  DCPS  relational 
models  or  build  an  object  model  atop  the 
DLRL.  Data  associated  with  DDS  topics 
are  expressed  using  types  defined  by  the 
standard  OMG  Interface  Definition 
Language  (IDL),  which  simplifies  the 
inter-working  between  DDS  and  CORBA. 
Relationships  between  topics  can  be  cap¬ 
tured  via  keys  that  can  be  used  to  distin¬ 
guish  between  different  instances  of  the 
same  topic. 


In  net- centric  tactical  information  sys¬ 
tems,  an  information  model  will  be  associ¬ 
ated  with  every  layer  in  which  DDS-based 
data  exchange  occurs.  This  information 
model,  which  can  comply  with  DoD  or 
North  American  Trade  Organization  stan¬ 
dards,  is  the  lingua  franca  used  by  the  dif¬ 
ferent  applications  in  coalitions  to 
exchange  information  and  seamlessly 
interoperate.  Likewise,  the  QoS  policies 
decorating  the  information  model  deter¬ 
mine  how  the  data  is  disseminated,  per¬ 
sisted,  and  received  in  the  global  data 
space. 

Publishers  and  Subscribers 

In  net-centric  tactical  information  man¬ 
agement  systems,  publishers  and  sub¬ 
scribers  correspond  to  a  range  of  domain 
participants  such  as  embedded  devices. 
Unmanned  Air  Vehicles  (UAVs),  soldiers’ 
equipment,  as  well  as  planning  and  simula¬ 
tion  services  in  operations  centers.  DDS 
applications  use  data  writers  to  publish 


Figure  2:  DDS  Global  Data  Space  in  a  Domain 
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Figure  3:  DDS  Topic 

data  values  to  the  global  data  space  of  a 
domain  and  data  readers  to  receive  data.  A 
publisher  is  a  factory  that  creates  and 
manages  a  group  of  data  writers  with  sim¬ 
ilar  behavior  or  QoS  policies,  as  shown  in 
Figure  4.  A  subscriber  is  a  factory  that  cre¬ 
ates  and  manages  data  readers,  as  shown 
in  Figure  4. 

Publishers  can  declare  their  intent  to 
produce  data  on  particular  topics  with 
associated  QoS,  and  they  distribute  the 
data  on  those  topics  to  the  global  data 
space.  Subscribers  receive  topic  data  in  the 
global  data  space  that  match  their  sub¬ 
scriptions  (the  rules  that  define  what  rep¬ 
resents  a  matching  subscription  are 
described  below).  QoS  policies  allow  pub¬ 
lishers  and  subscribers  to  define,  first, 
their  local  behavior,  such  as  the  number  of 
historical  data  samples  they  require  and 
the  maximum  update-rate  at  which  they 
want  to  receive  data,  and,  second,  how 
data  should  be  treated  once  in  transit  with 
respect  to  reliability,  urgency,  importance, 
and  durability.  Topics  can  also  be  annotat¬ 
ed  with  these  QoS  policies  to  drive  the 
behavior  of  the  data-distribution.  The 
QoS  policies  of  pre-defined  topics  serve 
as  defaults  for  publishers  and  subscribers 
and  can  therefore  ensure  consistency 
between  requested  and  offered  QoS. 

Subscriptions  and  Matching 

A  subscription  is  an  operation  that  associ¬ 
ates  a  subscriber  to  its  matching  publish¬ 
ers,  as  shown  in  the  center  of  Figure  4.  In 
addition  to  the  topic-based  subscriptions 


described,  DDS  also  supports  content-based 
subscription ,  in  which  a  subset  of  the  stan¬ 
dard  Structured  Query  Language  (SQL)  is 
used  to  specify  subscription  filters.  In 
DDS  a  matching  subscription  must  match 
the  following  two  types  of  a  topic’s  prop¬ 
erties:  (1)  its  features,  such  as  its  type, 
name,  key,  and  content;  (2)  its  QoS  poli¬ 
cies,  which  are  described  in  th zQoS  Policies 
section. 

The  matching  process  for  QoS  uses  a 
requested/offered  (RxO)  model  shown  in 
Table  1,  where  the  requested  QoS  must  be 
less  than  or  equal  to  the  offered  QoS.  For 
example,  subscribers  requesting  reliable 
data  delivery  cannot  communicate  with 
publishers  that  only  distribute  data  using 
best  effort  delivery.  Likewise,  subscribers 
cannot  request  a  topic  update  whose  dead¬ 
line  is  smaller  than  that  declared  by  any 
publishers. 

The  subscription  matching  mechanism 
provided  by  DDS  enforces  a  powerful 
form  of  design  by  contract  [4] ,  where  QoS  is 
used  together  with  type  information  to 
decide  whether  publishers  and  subscribers 
can  communicate.  This  extended  form  of 
design  by  contract  helps  ensure  that  net- 
centric  systems  will  operate  as  intended, 
both  from  functional  and  QoS  perspec¬ 
tives.  These  assurances  are  essential  in  the 
development,  deployment,  and  operation 
of  mission-critical  net-centric  tactical 
information  management  systems. 

Discovery 

Another  key  feature  of  DDS  is  that  all 
information  needed  to  establish  commu¬ 
nication  can  be  discovered  automatically, 
in  a  completely  distributed  manner. 
Applications  dynamically  declare  their 
intent  to  become  publishers  and/or  sub¬ 
scribers  of  one  or  more  topics  to  the  DDS 
middleware,  which  uses  this  information 
to  establish  the  proper  communication 
paths  between  discovered  entities.  This 


capability  supports  dynamic  scenarios 
common  in  net-centric  tactical  informa¬ 
tion  management  where  cooperating 
domain  participants  join  and  leave 
throughout  system  operation. 

QoS  Policies 

DDS  is  designed  for  mission-critical  net- 
centric  systems  where  the  right  answer 
delivered  too  late  becomes  the  wrong 
answer.  To  meet  timing  requirements  it  is 
essential  that  the  middleware  controls  and 
optimizes  the  use  of  resources,  such  as  net¬ 
work  bandwidth,  memory,  and  CPU  time. 
Table  1  shows  the  rich  set  of  QoS  policies 
that  DDS  provides  to  control  and  limit 
topic  (1),  data  reader  (DR),  data  writer 
(DW),  publisher  (P),  and  subscriber  (S) 
resources  and  topic  QoS  properties,  such 
as  persistence,  reliability,  and  timeliness  [2]. 
Below  we  discuss  the  DDS  QoS  policies 
that  are  the  most  relevant  for  net-centric 
tactical  information  management  systems. 

Data  Availability 

DDS  provides  the  following  QoS  policies 
that  control  the  availability  of  data  to 
domain  participants: 

•  The  Durability  QoS  policy  controls 
the  lifetime  of  the  data  written  to  the 
global  data  space  in  a  domain. 
Supported  durability  levels  include  the 
following:  (1)  volatile,  which  specifies 
that  once  data  is  published  it  is  not 
maintained  by  DDS  for  delivery  to  late 
joining  applications;  (2)  transient  local, 
which  specifies  that  publishers  store 
data  locally  so  that  late  joining  sub¬ 
scribers  get  the  last  published  item  if  a 
publisher  is  still  alive;  (3)  transient, 
which  ensures  that  the  global  data 
space  maintains  the  information  out¬ 
side  the  local  scope  of  any  publishers 
for  use  by  late  joining  subscribers;  and 
(4)  persistent,  which  ensures  that  the 
global  data  space  stores  the  informa¬ 
tion  persistently  so  it  is  available  to  late 
joiners  even  after  the  shutdown  and 
restart  of  the  system.  Durability  is 
achieved  by  relying  on  a  durability  ser¬ 
vice  whose  properties  are  configured 
by  means  of  the  DURABILITY_SER- 
VICE  QoS. 

•  The  LIFESPAN  QoS  policy  controls 
the  interval  of  time  during  which  a 
data  sample  is  valid.  The  default  value 
is  infinite,  with  alternative  values  being 
the  time- span  for  which  the  data  can 
be  considered  valid. 

•  The  HISTORY  QoS  policy  controls 
the  number  of  data  samples  (i.e.,  sub¬ 
sequent  writes  of  the  same  topic)  that 
must  be  stored  for  readers  or  writers. 
Possible  values  are  the  last  sample,  the 


Figure  4:  DDS  Publisher!  Writer  Subscriber/  Peader  and  Subscription/ QoS  Matching 
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Table  1:  Key  QoS  Policies  for  Net-Centric  Systems 


last  n  samples,  or  all  samples. 

These  QoS  policies  provide  the  DDS 
global  data  space  with  the  ability  to  coop¬ 
erate  in  highly  dynamic  environments 
characterized  by  continuous  joining  and 
leaving  of  publisher/ subscribers.  This 
capability  makes  it  possible  for  net-centric 
tactical  information  management  systems 
to  share  a  common  operational  picture 
regardless  of  the  dynamism  that  charac¬ 
terizes  portions  of  the  systems,  such  as 
coalitions  of  soldiers  collaborating  in 
urban  environments  or  coordinated  UAVs 
in  support  of  tactical  operations. 

Data  Delivery 

DDS  provides  the  following  QoS  policies 
that  control  how  data  is  delivered  and 
which  publishers  are  allowed  to  write  a 
specific  topic: 

•  The  PRESENTATION  QoS  policy 
gives  control  on  how  changes  to  the 
information  model  are  presented  to 
subscribers.  This  QoS  gives  control  on 
the  ordering  as  well  as  the  coherency 
of  data  updates.  The  scope  at  which  it 
is  applied  is  defined  by  the  access 
scope,  which  can  be  one  of 
INSTANCE,  TOPIC,  or  GROUP 
level. 

•  The  RELIABILITY  QoS  policy  con¬ 
trols  the  level  of  reliability  associated 
with  data  diffusion.  Possible  choices 
are  RELIABLE  and  BEST_EFFORT 
distribution. 

•  The  PARTITION  QoS  policy  gives 
control  over  the  association  between 
DDS  partitions  (represented  by  a 
string  name)  and  a  specific  instance  of 
a  publisher/ subscriber. 

•  The  DESTINATION_ORDER  QoS 
policy  controls  the  order  of  changes 
made  by  publishers  to  some  instance 
of  a  given  topic.  DDS  allows  the 
ordering  of  different  changes  accord¬ 
ing  to  source  or  destination  time- 
stamps. 

•  The  OWNERSHIP  QoS  policy  con¬ 
trols  which  writer  owns  the  write- 
access  to  a  topic  when  there  are  multi¬ 
ple  writers  and  ownership  is  EXCLU¬ 
SIVE.  Only  the  writer  with  the  highest 
OWNERSHIP_STREN  GTH  can 
publish  the  data.  If  the  OWNERSHIP 
QoS  policy  value  is  shared,  multiple 
writers  can  concurrently  update  a 
topic.  OWNERSHIP  thus  helps  to 
manage  replicated  publishers  of  the 
same  data. 

These  QoS  policies  control  the  relia¬ 
bility  and  availability  of  the  data,  thus 
allowing  the  delivery  of  the  right  data  to 
the  right  place  at  the  right  time.  More  elab¬ 
orate  ways  of  selecting  the  right  data  are 


offered  by  the  DDS  content-awareness 
profile  that  allows  applications  to  select 
information  of  interest  based  upon  their 
content. 

Data  Timeliness 

DDS  provides  the  following  QoS  policies 
that  control  the  timeliness  properties  of 
distributed  data: 

•  The  DEADLINE  QoS  policy  allows 
applications  to  define  the  maximum 
inter- arrival  time  for  data.  DDS  can  be 
configured  to  automatically  notify 
applications  when  deadlines  are 
missed. 

•  The  LATEN CY_BUDGET  QoS  pol¬ 
icy  provides  a  means  for  applications 
to  inform  DDS  of  the  urgency  associ¬ 
ated  with  transmitted  data.  The  latency 
budget  specifies  the  time  period  with¬ 
in  which  DDS  must  distribute  the 
information.  This  time  period  starts 
from  the  moment  the  data  is  written 
by  a  publisher  until  it  is  available  in  the 
subscriber’s  data-cache  ready  for  use 
by  reader(s). 

•  The  TRANSPORT_PRIORITY  QoS 
policy  allows  applications  to  control 
the  importance  associated  with  a  topic 


or  with  a  topic  instance,  thus  allowing 
a  DDS  implementation  to  prioritize 
more  important  data  relative  to  less 
important  data. 

These  QoS  policies  make  it  possible  to 
ensure  that  tactical  information  needed  to 
reconstruct  the  shared  operational  picture 
is  delivered  in  a  timely  manner. 

Resources 

DDS  defines  the  following  QoS  policies 
to  control  the  network  and  computing 
resources  that  are  essential  to  meet  data 
dissemination  requirements: 

•  The  TIME_BASED_FILTER  QoS 
policy  allows  applications  to  specify 
the  minimum  inter- arrival  time 
between  data  samples,  thereby 
expressing  their  capability  to  consume 
information  at  a  maximum  rate. 
Samples  that  are  produced  at  a  faster 
pace  are  not  delivered.  This  policy 
helps  a  DDS  implementation  optimize 
network  bandwidth,  memory,  and  pro¬ 
cessing  power  for  subscribers  that  are 
connected  over  limited  bandwidth  net¬ 
works  or  which  have  limited  comput¬ 
ing  capabilities. 

•  The  RESOURCE_LIMITS  QoS  poli- 


March  2008 


www.stsc.hill.af.mil  27 


Software  EngineeringTechnology 


cy  allows  applications  to  control  the 
amount  of  message  buffering  per¬ 
formed  by  a  DDS  implementation. 
DDS’s  QoS  policies  support  the  vari¬ 
ous  elements  and  operating  scenarios  that 
constitute  net-centric  tactical  information 
management.  By  controlling  these  QoS 
policies  it  is  possible  to  scale  DDS  from 
low-end  embedded  systems  connected 
with  narrow  and  noisy  radio  links,  to  high- 
end  servers  connected  to  high-speed 
fiber-optic  networks. 

Configuration 

The  QoS  policies  described  above  provide 
control  over  the  most  important  aspects 
of  data  delivery,  availability,  timeliness, 
and  resource  usage.  In  addition,  DDS  also 
supports  the  definition  and  distribution  of 
user  specified  bootstrapping  information 
via  the  following  QoS  policies: 

•  The  USER  DATA  QoS  policy  allows 
applications  to  associate  a  sequence  of 
octets  to  domain  participant  data  read¬ 
ers  and  data  writers.  This  data  is  then 
distributed  by  means  of  the  DCPS 
participant  built-in  topic.  This  QoS 
policy  is  commonly  used  to  distribute 
security  credentials. 

•  The  TOPIC_DATA  QoS  policy 
allows  applications  to  associate  a 
sequence  of  octets  with  a  topic.  This 
bootstrapping  information  is  distrib¬ 
uted  by  means  of  the  DCPS  Topic 
built-in  topic.  A  common  use  of  this 
QoS  policy  is  to  extend  topics  with 
additional  information,  or  meta-infor¬ 
mation,  such  as  extensible  Markup 
Language  schemas. 

•  The  GROUP_DATA  QoS  policy 
allows  applications  to  associate  a 
sequence  of  octets  with  publishers  and 
subscribers.  This  bootstrapping  infor¬ 
mation  is  distributed  by  means  of  the 
DCPS  subscription, and  DCPS  publi¬ 
cation  built-in  topics,  respectively.  A 
typical  use  of  this  information  is  to 
allow  additional  application  control 
over  subscriptions  matching. 

DDS  Success  Stories 

Although  DDS  is  a  relatively  new  standard 
(adopted  by  the  OMG  in  2004),  it  has 
been  adopted  quickly  due  to  its  ability  to 
address  key  requirements  of  data  distribu¬ 
tion  in  net-centric  systems,  as  well  as  the 
maturity  and  quality  of  available  imple¬ 
mentations,  which  are  based  on  decades  of 
experience  developing  data-centric  mid¬ 
dleware  for  mission-critical  systems. 
Moreover,  DDS  has  been  mandated  by 
the  U.S.  Navy’s  Open  Architecture 
Computing  Environment  as  the  standard 
publish/ sub  scribe  technology  to  use  in 


next-generation  combat  management  sys¬ 
tems,  and  Defense  Information  Systems 
Agency  as  the  standard  technology  for 
publish/ subscribe  to  be  used  in  all  new  or 
upgraded  systems  [5,  6].  Several  major 
defense  programs,  such  as  the  U.S.  Navy’s 
DDG-1000  land  attack  destroyer,  U.S. 
Army’s  Future  Combat  Systems  (FCS), 
and  the  Thales  Tactical  Information  And 
Command  System  Operating  System 
(TACTIC OS),  also  adopted  DDS  even 
before  it  was  mandated,  underscoring 
DDS’  ability  to  address  the  data  distribu¬ 
tion  challenges  of  next  generation  net- 
centric  defense  systems. 

For  example,  the  TACTICOS  combat 
management  system  developed  by  Thales 
Naval  Netherlands  is  based  on  an  imple¬ 
mentation  of  DDS  that  allows  them  to 
achieve  very  good  scalability,  from  small 


“DDS  provides  the 
fault-tolerant  information 
backbone  onto  which 
all  these  applications  are 
deployed  and  is  thus 
responsible  for  providing 
each  application  with 
the  right  information 
at  the  right  t/me.” 

ships  to  aircraft  carrier  grade,  as  well  as 
high  performance,  availability,  and  deter¬ 
minism  even  under  temporary  overload 
conditions  [7,  8].  TACTICOS  is  currently 
in  use  in  15  navies  worldwide  serving  20 
ships-classes  ranging  from  small  patrol 
boats  up  to  large  frigates.  The  utilization 
of  DDS  is  instrumental  in  its  success 
since  it  provides  both  the  scalability  to 
support  thousands  of  applications  run¬ 
ning  on  more  than  150  distributed  com¬ 
puters  on  a  frigate  size  system.  Another 
key  feature  of  DDS  is  its  battle-damage 
resistance,  meaning  that  software  can  be 
dynamically  re-allocated  to  the  remaining 
computer  pool  in  case  of  an  error  on  a 
specific  computer.  The  DDS  Persistence 
Profile  support  is  instrumental  in  this 
dynamic  reallocation  since  it  allows  appli¬ 
cations  to  store  their  internal  state  into  the 
DDS  middleware,  which  manages  this 
state  in  a  distributed  and  fault- tolerant  way 
so  that  restarted  applications  can  continue 
what  they  were  doing  before  they  crashed. 


The  DDS  implementation  used  on 
TACTICOS  supports  a  data-centric 
approach  where  at  the  start  of  the  system 
design,  the  information  model  can  be  cap¬ 
tured,  annotated  with  proper  QoS  poli¬ 
cies,  and  then  shared  between  multiple 
parties.  This  federated  architecture  is  com¬ 
mon  in  existing  and  planned  coalition-based 
developments  where  multiple  parties 
jointly  implement  the  overall  combat  sys¬ 
tem.  DDS  provides  the  fault-tolerant 
information  backbone  onto  which  all 
these  applications  are  deployed  and  is  thus 
responsible  for  providing  each  application 
with  the  right  information  at  the  right 
time. 

Along  with  the  rapid  adoption  of 
DDS  in  the  defense  domain,  its  use  is  also 
steadily  growing  in  other  domains,  such  as 
transportation,  telecommunications,  and 
finance.  For  example,  in  the  context  of 
Air  Traffic  Control  and  Management, 
DDS  has  been  selected  as  the 
publish/ subscribe  middleware  for  distrib¬ 
uting  flight  data  plans  in  CoFlight  [9], 
which  is  the  next  generation  European 
Flight  Data  Processor.  In  general,  DDS  is 
an  appropriate  middleware  technology  for 
application  domains  that  require  rich  sup¬ 
port  for  QoS  policies  and  high-perfor¬ 
mance  and  dependability  standards-based, 
commercial-off-the-shelf  implementa¬ 
tions. 

Concluding  Remarks 

DDS  is  a  standards-based  QoS-enabled 
data-centric  publish/ subscribe  middle¬ 
ware  that  provides  a  feature  rich  data-cen¬ 
tric  real-time  platform  to  support  the 
needs  of  current  and  planned  net-centric 
tactical  information  management  systems. 
Its  powerful  set  of  QoS  policies,  together 
with  its  scalable  architecture,  makes  it  an 
effective  and  mature  choice  for  solving  the 
data  distribution  and  information  manage¬ 
ment  problems  net-centric  systems  [10]. 
Next,  we  summarize  how  DDS  addresses 
the  key  challenges  outlined  in  the  intro¬ 
duction  in  a  standard  and  interoperable 
manner: 

•  Shared  operational  picture.  DDS 

provides  effective  support  for  these 
types  of  applications  via  its  QoS  poli¬ 
cies  for  defining  the  scope,  content, 
and  QoS  of  the  data  model  that  under¬ 
lies  the  operational  picture. 

•  The  right  data  at  the  right  time  at 
the  right  place  via  DDS  QoS  policies 
that  enable  a  fine-grained  control  over 
information  delivery,  such  as  the  abili¬ 
ty  to  control  many  aspects  of  data  dis¬ 
semination  to  ensure  timely  delivery 
and  optimal  resource  usage. 

•  Heterogeneous  environment.  By 
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providing  standard  QoS  policies  that 
control  the  bandwidth  used  for  pro¬ 
viding  data  to  interested  parties,  DDS 
runs  in  heterogeneous  platforms  while 
providing  different  elements  with  a 
common  operational  picture. 

•  Dynamic  coalitions.  The  highly 
dynamic  nature  of  DDS,  such  as  its 
support  for  dynamic  discovery,  pro¬ 
vides  an  effective  platform  for  sup¬ 
porting  ad  hoc  interactions. 

DDS  continues  to  evolve  to  meet  new 
operational  and  technical  challenges  of 
net-centric  tactical  information  manage¬ 
ment  systems.  Three  types  of  extensions 
are  currently  being  pursued  for  DDS  by 
the  OMG.  The  first  involves  adding  new 
platform- specific  models  that  fully  lever¬ 
age  programming  language  features,  such 
as  standard  C++  containers.  The  second 
extension  deals  with  extensible  topics  that 
enable  incremental  system  updates  by 
ensuring  that  changes  in  the  data  model 
do  not  break  interoperability.  The  final  set 
of  extensions  focus  on  network  data  rep¬ 
resentation  and  the  syntax  used  to  define 
topics.  For  example,  upcoming  versions  of 
the  DDS  standard  will  likely  allow  the  def¬ 
inition  of  topics  using  XML,  as  well  as  the 
use  of  XML  or  Java  Script  Object 
Notation  as  the  network  data  representa¬ 
tion.  DDS  security  has  not  yet  been  stan¬ 


dardized.  The  OMG  will  be  addressing 
this  area  of  standardization  starting  in  the 
spring  of  2008. 

With  multiple  COTS  and  open-source 
implementations  and  a  solid  track  record 
of  success  in  mission-critical  military  and 
commercial  projects,  DDS  has  a  bright 
future  as  the  standards-based  middleware 
of  choice  for  net-centric  tactical  informa¬ 
tion  systems.  More  information  on  DDS 
and  its  application  in  practice  are  available 
in  online  forums  [11,  12]  where  experts 
discuss  advanced  features  of  the  DDS 
standard  and  new  directions  for  the  tech¬ 
nology,  while  DDS  beginners  can  learn 
from  past  experiences  and  ask  questions 
about  patterns  and  best  practices  for 
applying  DDS  in  their  net-centric  sys- 
tems.^ 
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tems,  large-scale,  and  very  large-scale 
distributed  systems  such  as  defense, 
aerospace,  homeland  security  and  trans¬ 
portation  systems. 
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PrismTech,  he  worked  at  Thales  Naval 
Netherlands  (TNN)  where  he  was 
responsible  for  the  development  of  the 
data-centric  real-time  middleware  as 
applied  in  TNN’s  combat  system  in  ser¬ 
vice  with  1 5  navies  worldwide. 
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Departments 


Welcome  to  the  20th  installment  of  the  Systems  and 
Software  Technology  Conference  (SSTC).  Just  about 
20  years  ago,  Tetris  was  becoming  the  computer  game 
of  choice.  VGA  Graphics  were  gaining  in  popularity.  A 
company  known  by  its  initials,  IBM,  was  delivering  the 
PS/2  computer.  It  had  a  funny  new  pointing  device  -  a 
mouse.  And  the  first  ever  Software  Technology  Conference 
was  held.  From  the  beginning,  SSTC  has  focused  on 
technology  relating  to  the  Department  of  Defense.  We 
begin  another  decade  with  this  same  focus. 


Our  theme  will  be  " Technology :  Tipping  the  Balance" 

The  idea  behind  the  theme  is  to  explore  new  and  needed 
technologies,  as  well  as  lessons  learned,  which  tip  the 
balance  in  the  favor  of  our  Defense  Services,  providing 
them  an  asymmetric  advantage. 


Submittal  Topics  Included: 

•  Assurance  and  Security 

•  Estimating  and  Measuring 

•  Lessons  Learned 

•  New  Concepts  and  Trends 

•  Policy  and  Standards 

•  Processes  and  Methods 

•  Professional  Development 

•  Robust  Engineering 

•  Systems:  from  Design  to  Delivery 


Who  Should  Attend: 

•  Acquisition  Professionals 

•  Prog  ram/ Project  Managers 

•  Programmers 

•  System  Developers 

•  Systems  Engineers 

•  Process  Engineers 

•  Quality  and  Test  Engineers 


For  Complete  Conference  &  Trade  Show  Information 

www.sstc-onl ine.org 

REGISTER  TODAY! 
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BackTalk 


Marathon  or  Sprint? 


Recently,  I  had  the  opportunity  to  be  stuck  in  an  airplane  in 
Albuquerque,  heading  towards  Atlanta.  We  boarded  the 
plane  a  few  minutes  late,  but  managed  to  pull  out  of  the  gate  and 
head  to  the  runway  within  10  minutes  of  the  scheduled  time. 

Once  we  got  to  the  runway,  we  sat.  And  sat.  And  sat... 
Eventually,  the  plane  engines  sped  up,  and  everyone  breathed  a 
sign  of  relief  as  the  plane  departed.  Unfortunately,  all  it  did  was 
move  forward  a  few  hundred  feet,  take  a  taxiway,  and  head  back 
towards  the  terminal.  Passengers  were  immediately  asking 
“What’s  happening?”  The  flight  attendants  never  made  an 
announcement  and  neither  did  the  flight  crew.  People  started 
calling  on  their  cell  phones,  initializing  the  frantic  can-I-get- 
rehooked-on-another-flight-or-airline?  calls. 

We  approached  the  terminal  and  stopped  short.  At  that  time, 
the  pilot  finally  came  on  the  intercom  and  said,  “The  tempera¬ 
ture/humidity  conditions  are  marginal,  so  we’ve  decided  to  de¬ 
ice  the  plane  before  takeoff.  We’ll  be  off  in  1 5  minutes,  and  we’re 
predicting  that  we’ll  arrive  in  Atlanta  only  5  to  10  minutes  late. 
Everybody  should  have  no  problem  making  their  connections.” 
There  were  massive  sighs  of  relief  as  we  all  smiled  and  realized 
that  there  were  no  catastrophic  schedule  changes  in  store  for  us. 
Everybody  relaxed,  except  for  me  —  I  thought  of  how  this  would 
be  a  perfect  topic  for  a  BackTalk. 

In  software  development,  we  also  have  passengers.  We  call 
them  customers.  And,  just  like  the  passengers  on  the  airplane, 
they  feel  they  have  a  right  to  know  what  is  happening. 

The  problem  arises  when  it  comes  down  to  How  Much  Ho  I 
Tell  My  Customer?  At  what  level  do  you  start  sharing  (infrequent) 
good  and  (frequent)  bad  news? 

I  have  consulted  on  software  projects  that  have  ranged  from 
full  and  open  communication  to  just  keep  telling  them  we  are  on  sched¬ 
ule.  And,  as  expected,  these  projects  have  also  ranged,  in  a  differ¬ 
ent  dimension,  from  “Wow  -  delivered  on  time  and  on  budget!” 
to  “Well,  time  to  update  the  old  resume.”  And  in  all  cases,  open 
communication  made  the  difference  between  (on  yet  another 
dimension)  “Wow,  what  a  great  team  of  developers!”  to  “Can 
Tony  Soprano  arrange  a  hit  for  me?” 

Here’s  a  secret:  All  software  development  projects  have  a  lot  of 
politics  involved.  And,  to  misquote  a  famous  author1,  “Politics  are 
like  sausages  —  it  is  best  not  to  watch  them  being  made.”  Internal 
politics  make  for  changes,  changes  result  in  bad  news,  and  that 
requires  communication  between  developers  and  customers. 

On  the  developer  side,  people  come  and  go.  Good  develop¬ 
ers  often  leave,  retire,  get  sick,  take  a  better  job,  burn  out,  freak 
out,  sneak  out. .  .you  get  the  picture.  They  hire  new  personnel, 
retrain  others  from  other  projects  (projects  that  have  had  their 
budget  cut,  were  cancelled,  etc).  Critical  folks  take  leave  at  the 
worst  time.  And  every  time  developer  staff  changes,  productivi¬ 
ty  metrics  changes.  Earned  value  moves  around 

On  the  customer  side,  requirements  change.  Frequently.  Not 
because  we  didn’t  know  them,  but  because  of  politics.  The  nine 
different  stakeholders  can’t  agree  on  interfaces.  Small  issues 
become  huge  (and  yet,  huge  issues  seldom  become  trivial  —  pity). 

And  through  it  all,  both  sides  have  to  develop  a  cutoff  bar  of 
how  much  information  is  shared  with  the  other  side.  It’s  not  about 
us  vs.  them,  it’s  about  politics.  It’s  about  contract  issues.  It’s  about 
budgeting.  But,  underneath  it  all,  it’s  about  trying  to  get  the  project 
finished  on  time,  on  budget,  and  with  happy  end  users.  Delivering 
bad  news  is  never  a  good  thing  -  but  it’s  often  a  necessary  thing. 


Being  a  good  consultant,  I  have  a  workable  answer  to  the 
question  how  much  information  do  I  share ?  Put  yourselves  in  their 
shoes,  and  ask  yourself  would  their  job  be  easier  if  they  knew 
more  about  the  politics  that  I  am  involved  in?  Can  I  tell  them 
additional  information  about  upcoming  events  without  doing 
damage  to  myself  (or  my  organization)? 

You  don’t  want  to  be  one  of  the  pick-up-the-phone-and-tell- 
them-everything  kind.  You  need  a  filter  mechanism  to  filter  out 
garbage  and  a  metric  to  figure  out  how  much  to  tell  them.  It 
probably  requires  a  centralized  communication  channel  —  don’t 
undercut  the  boss  by  telling  the  other  side  things  he  or  she  might 
not  want  discussed. 

The  best  advice  I  have  ever  seen  given  to  a  development  team 
was  “Remember,  it’s  a  marathon,  not  a  sprint2.”  In  case  you  don’t 
know  the  origin  of  the  word  marathon,  it  comes  from  the  legend 
of  Pheidippides,  a  Greek  soldier,  who  was  sent  from  the  town  of 
Marathon  to  Athens  to  announce  that  the  Persians  had  been 
defeated  in  the  Battle  of  Marathon.  It  is  said  that  he  ran  the 
entire  distance  without  stopping  and  burst  into  the  senate  with 
the  words  “Masters!  Victory  is  ours!”  before  collapsing  and  dying 
due  to  exhaustion. 

I  don’t  think  the  messenger  (or  the  project)  should  die. 
Marathon  was  about  a  victory,  not  a  defeat!  When  we  win  the  bat¬ 
tle,  as  we  cross  the  finish  line,  we  might  be  exhausted  in  victory, 
but  it  will  be  because  of  the  words  we  have  said  up  to  that  point, 
not  what  we  gasp  as  we  finish.  Please  don’t  kill  the  messenger. 

—  David  A.  Cook 

dcook@aegistg.com 
The  AEgis  Technologies  Group,  Inc. 

Notes 

1.  Nobody  really  knows  who  said  “Laws  are  like  sausages  —  it  is 
best  not  to  see  them  being  made.”  See  <http://en.wiki 
quote.org/wiki/Otto_von_Bismarck>.  It  has  been  attributed 
to  Otto  von  Bismarck,  Winston  Churchill,  Benjamin  Disraeli, 
Clarence  Darrow,  Mark  Twain,  and  Kaiser  Wilhelm,  among 
others. 

2.  Oddly  enough,  the  development  team  was  using  the  Agile 
methodology  Scrum,  which  has  periods  of  development 
called  “Sprints.”  Come  on,  this  is  funny!  And  thanks  to  Mark 
Mitchell  for  repeating  this  advice  frequently  <http:// 
en.wikipedia.org/ wiki/Mara  thon>. 

Can  You  BACKTALK? 

Here  is  your  chance  to  make  your  point,  even  if  it  is  a  bit 
tongue-in-cheek,  without  your  boss  censoring  your  writing.  In 
addition  to  accepting  articles  that  relate  to  software  engineer¬ 
ing  for  publication  in  CROSSTALK,  we  also  accept  articles  for 
the  BackTalk  column.  BackTalk  articles  should  provide  a 
concise,  clever,  humorous,  and  insightful  perspective  on  the 
software  engineering  profession  or  industry  or  a  portion  of  it. 
Your  BackTalk  article  should  be  entertaining  and  clever  or 
original  in  concept,  design,  or  delivery.  The  length  should  not 
exceed  750  words. 

For  a  complete  author’s  packet  detailing  how  to  submit 
your  BackTalk  article,  visit  our  Web  site  at 
<www.stsc.hill.af.mil>. 
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NAVAIR'S  Strategic  Priorities 

Current  Readiness 

Contribute  to  delivering  Naval  aviation  units  ready  for  tasking  with  the 
right  capability,  at  the  right  time,  and  the  right  cost. 

Future  Capability 

Deliver  new  aircraft,  weapons,  and  systems  on  time  and  within 
budget,  that  meet  Fleet  needs  and  provide  a  technological  edge  over 
our  adversaries. 


People 

Develop  our  people  and  provide  them  with  the  tools,  infrastructure, 
and  processes  they  need  to  do  their  work. 
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